Feedback on svn-1333

[rpedde]

@grommet wrote:

I still have to dig deeper, but it seems some of my track names/titles turned into filenames on a full rebuild scan (still svn-1333)… but only if the track was referenced in a .m3u based playlist. Not sure what is going on here… the rest of the metadata for the track is populated correctly. ❓

Is your music someplace other than “My Music”?

Can you try making hte directory that hte actually music lives in the first directory in your mp3_dir, then any other after that?

[grommet]

Yes, the content is in the first mp3_dir referenced… in fact, on this particular platform… it is the only directory referenced and is the ‘Windows default’ long & painful ‘My Music’ directory path. The .m3u entries used relative directory pointers… for example: ..LunaRomantica8 – 1995.wma The odd part is that it’s not every entry. I guess I should try putting the full path in the .m3u… to see if the behavior changes on scan…

[rpedde]

@grommet wrote:

Yes, the content is in the first mp3_dir referenced… in fact, on this particular platform… it is the only directory referenced and is the ‘Windows default’ long & painful ‘My Music’ directory path. The .m3u entries used relative directory pointers… for example: ..LunaRomantica8 – 1995.wma The odd part is that it’s not every entry. I guess I should try putting the full path in the .m3u… to see if the behavior changes on scan…

Generally, the music scanning is done in two passes. First is to index the music files, and m3u/xml files are noted and saved for the second pass. Once the first pass is done, then then playlists are processed.

If the playlists reference a file that isn’t in the database, it gets added.

The problem is that if there are no actual files in your mp3_dir, and you are relying on playlists (xml or m3u) to find songs and add them, then they get added after the song transactions are complete, which means updating indexes, etc. If the songs are added during the first pass, they are added without checking to see if they already exists, and without indexes, and inside a transaction, which is much faster.

So upshot is that if you catch the files during the song scan, then performance will be much better. So make sure the path with the actual music is in one of your mp3_dirs.

That’s the only thing I can think of.

Hrm. Let me double-check to make sure I’m not making the indexes when starting the initial scan, though.

[grommet]

I never reference tracks I don’t have in mp3_dir… so it should be fine.

More oddness: I removed the .m3u, did a full database scan and restart… so everything was “correct” as expected. Then I added back the .m3u Playlist… did a restart/rescan of Firefly… and it changed the track name of all the “.wma” files in the playlist to the full filename. (The same .wma tracks had the correct title in the library before the scan.) As before, the other metadata is correct… just the name is wrong. ❓ I’m getting confused here; not sure what path to go to narrow this down. 😕

[grommet]

Bug reported in Roku forum, which I repro’d:
http://www.rokulabs.com/forums/viewtopic.php?t=8677

Issue with directory called “Café Blue” – Firefly svn-1333 can’t open file to play until directory is renamed to something without the é.

[rpedde]

@grommet wrote:

I never reference tracks I don’t have in mp3_dir… so it should be fine.

More oddness: I removed the .m3u, did a full database scan and restart… so everything was “correct” as expected. Then I added back the .m3u Playlist… did a restart/rescan of Firefly… and it changed the track name of all the “.wma” files in the playlist to the full filename. (The same .wma tracks had the correct title in the library before the scan.) As before, the other metadata is correct… just the name is wrong. ❓ I’m getting confused here; not sure what path to go to narrow this down. 😕

Different case? That’s the side effect of keeping case on playlist names — files aren’t normalized to lower case, and firefly ends up seeing them as different files.

[grommet]

I’m trying to get my head around this. 🙂 How do the entries/filenames referenced inside the Playlist fit into this? (And why just .wma in this scenaro?)

Also, something I did caused every song referenced in the .m3u playlist to show up with names/titles as filenames now… not just random ones (and not just .wma, like in the last test)… not sure what I did to trigger that. The long scan time bug is preventing me from really beating on it. (I might need to try a small library repro.)

My guess on the “.wma” only scenario was that the iTunes XML supplied the info for the .mp3 files referenced (no WMA in iTunes!)… and the Playlist was processed after the XML was done, but before Firefly finished it’s own scan? Possible? (But shouldn’t the scan replace the “name as filename” entry with the real name… since it populated the other metadata?) My head hurts. 8)

[rpedde]

@grommet wrote:

Also, something I did caused every song referenced in the .m3u playlist to show up with names/titles as filenames now… not just random ones (and not just .wma, like in the last test)… not sure what I did to trigger that. The long scan time bug is preventing me from really beating on it. (I might need to try a small library repro.)

My guess on the “.wma” only scenario was that the iTunes XML supplied the info for the .mp3 files referenced (no WMA in iTunes!)… and the Playlist was processed after the XML was done, but before Firefly finished it’s own scan? Possible? (But shouldn’t the scan replace the “name as filename” entry with the real name… since it populated the other metadata?) My head hurts. 8)

Yeah, I’m wondering if you are connecting before the scan is done, and you are seeing stuff before all the metadata gets filled.

Still wondering where all the time is.

Can you do a -d9 so I can see timestamps on what’s taking so long? I’m wondering if it’s a particular query or what….

[grommet]

Ok, what do you want me to debug 9? Do you want the initial scan? The rescan? (FYI: It takes just as long if I have no client trying to connect…) Maybe the playlist issues I’m seeing is pointless to chase until the post 1236 scan slowdown is identified and fixed? ❓

[rpedde]

@grommet wrote:

Ok, what do you want me to debug 9? Do you want the initial scan? The rescan? (FYI: It takes just as long if I have no client trying to connect…) Maybe the playlist issues I’m seeing is pointless to chase until the post 1236 scan slowdown is identified and fixed? ❓

If you can get both an initial scan and the rescan at 9, that would help. I want to see timestamps so I can see where it’s going slow, to help isolate the slowdown.

[Author]

Posts