Feature request: statistics tracking

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Tue Feb 21, 2012 12:00 pm

Would it be possible to implement stats tracking like this?

https://docs.google.com/document/d/16n8 ... UaekA/edit

Thanks in advance.

tamalet
Posts: 490
Joined: Fri Sep 24, 2010 4:34 am

Feature request: statistics tracking

Post by tamalet » Tue Feb 21, 2012 12:14 pm

The problem with this kind of tracking is performance.
Also most statistics and metadata like playcounts, raitings, labels and tags can be directly written to files, so if you them you just need to update the collection.

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Tue Feb 21, 2012 12:16 pm

I don't want to write stats to my files because there is more than one user of those files, so that's a non-solution.

Can you explain what the performance problem is, in more detail? Thanks in advance.

tamalet
Posts: 490
Joined: Fri Sep 24, 2010 4:34 am

Feature request: statistics tracking

Post by tamalet » Wed Feb 22, 2012 4:56 am

Do the other users use Guayadeque too? Playcounts, ratings and labels will only be visible to Guayadeque users.

Things like creating a unique id for each file will make the scanning process very slow. Even if it takes just a second per song, for collections of tens of thousands of songs will take several hours to complete.

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Wed Feb 22, 2012 9:52 am

Yes, other users use Guayadeque too, they have their own independent stats. As I said, writing per-user information in files is a non-solution. Perhaps you would consider writing this information in user.XXXX.YYYY extended attributes instead?

---------------------------------------

Creating a unique ID for each file should take less than a second with the algorithm I proposed. It would be content-based such that you don't have to worry about tags changing. It would *also* be optional.

Finally, generating unique file IDs should be done *in the background*, *after* scanning the library, rather than at the same time of the scan. Precisely so if the process is somehow "slow", it does not affect the use of Guayadeque -- it can always be completed incrementally and eventually.

tamalet
Posts: 490
Joined: Fri Sep 24, 2010 4:34 am

Feature request: statistics tracking

Post by tamalet » Wed Feb 22, 2012 10:15 am

I remember a similar suggestion was made in the old thread in Ubuntu forums. I supported the idea, but anonbeat said it would make the program slow.

Anyway, it could be investigated, the problem is always time and priorities. I suggest you write an idea in the IdeaTorrent so that others can vote: http://sourceforge.net/apps/ideatorrent ... eatorrent/

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Wed Feb 22, 2012 10:47 am

anonbeat is right if the implementation is poor. if the implementation is solid, it would make the program no slower than it is today.

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Thu Feb 23, 2012 4:08 pm

I posted an idea on ideatorrent.

tamalet
Posts: 490
Joined: Fri Sep 24, 2010 4:34 am

Feature request: statistics tracking

Post by tamalet » Sat Feb 25, 2012 6:23 am

It's now accepted.

tamalet
Posts: 490
Joined: Fri Sep 24, 2010 4:34 am

Feature request: statistics tracking

Post by tamalet » Sat Feb 25, 2012 7:16 am

I still have my doubts about how this could impact the performance.
Suppose that you rename a directory. Guayadeque will find a new directory for which it has not information. So if it wants to check whether it was in the library before to restore the statistics it will have to generate the UIDs for each of the files and if it finds the files, update the entries. All this would happen while updating the database and not "in the background".

And what if you have a file copied several times. Each copy will have its own statistics. Now suppose that you move 2 of them. How would it know which is which?

Post Reply