Implement a caching mechanism

Bug #392855 reported by Róbert Čerňanský on 2009-06-27
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
pytagsfs
Wishlist
Unassigned

Bug Description

With larger number of media files it takes long time to create the virtual filesystem. I believe this could be improved with some sort of caching mechanism because in most cases, real media files does not change very often.

The idea is that pytagsfs would store the data necesary for recreating virtual filesystem in the cache file(s). Structure of the cache file would be optimized for fast read access. Data in the cache file could consist of the whole tree of the real files with timestamps, tags that were read from files previously and list of virtual files that were created for particular real file (something like: Real_File_Or_Dir_Path, Modification_Time, Tags, List_Of_Virtual_Files_Paths).

When recreating the virtual filesystem, directories and files timestamps would be compared with cached ones. If timestamps not differ, virtual files would be created according List_Of_Virtual_Files_Paths, so no format parsing is needed here. If timestamps differ, virtual files would be created normally and entry in the cache updated.

Forest Bond (forest-bond) wrote :

Not the first time I've seen this request, although this is the first time we've had a ticket for it. This is the kind of work that I'd like to see go into the next major release, though.

I've been short on time lately, so I haven't been able to spend much of it on pytagsfs. I'd love to see some other folks get involved with pytagsfs development. If this is something that interests you, please join the mailing list. Patches can be submitted there for review, or you're also welcome to post a bzr branch implementing your changes. Otherwise, I do hope to get to this someday, but it may not be soon.

Thanks,
Forest

Changed in pytagsfs:
importance: Undecided → Wishlist
status: New → Confirmed
jtbm (webpostsaker) wrote :

I second this. A filesystem with approximately 400 GB of music took about two hours to mount four times. One by artist, one by album, one by file extension and one by genre. For me, the whole point of using this is getting some kind of order in all the files in directories named by different people in different ways.

The idea is splendid, and is exactly what I need, but it needs to be faster.
However, I'm not at programmer, I barely script in bash, so it would be difficult to assist in coding.

Excellent work anyway. I'm looking forward to using it in the future.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers