Bugzilla – Bug 1825
file urls get munged when playing other songs in folder using browse music folder and remote control
Last modified: 2009-09-08 09:31:47 UTC
str: - ensure play other songs in folder is enabled in server settings -> behavior - go to browse music folder using the remote, and press play on a song inside a folder that contains multiple songs - the first track that you hit play on will play, but the rest will not 2005-07-15 11:32:02.5116 00:04:20:81:22:33: Switching to mode play from stop 2005-07-15 11:32:02.5154 openSong on: 02.Love_Will_Keep_Us_Alive_(Live).flac Use of uninitialized value in concatenation (.) or string at /Users/kpearsall/trunk/server/Slim/Player/Source.pm line 1360. Use of uninitialized value in concatenation (.) or string at /Users/kpearsall/trunk/server/Slim/Player/Source.pm line 1360. 2005-07-15 11:32:02.5375 openSong: getting duration , size , endian and offset 0 for 02.Love_Will_Keep_Us_Alive_(Live).flac 2005-07-15 11:32:02.5389 openSong: not bothering opening file with zero size or duration 2005-07-15 11:32:02.5402 Error opening current track, so mark it as already played 2005-07-15 11:32:02.5467 Couldn't open song. Stopping. 2005-07-15 11:32:02.5483 opening next song... also lots of this: 2005-07-15 11:32:02.6409 Non-URL passed to InfoHash::info (03.The_Girl_From_Yesterday_(Live).flac) for each successive track in the playlist. it's just using only the filename for the URL, no actual url formatting...
Fixed as subversion change 3711.
at change 3713, I still can't see that this is fixed. Dumping the list is returning a list of track objects only for those scrolled on the player. The rest of the items are simple filenames. I guess those havent been converted by browseTreeItemName yet.
Created attachment 644 [details] items dump adding this dump at Command.pm line 1046: use Data::Dumper; print Dumper(parseListRef($client,$p2,$p3)); I get the attached output when I try to play a track. playtrackalbum is set to play all in folder, in the player I browse music folder, scroll down two items and press play. This is why I see 3 objects in the list. If I do not scroll, I get only one object.
Created attachment 652 [details] only on PLAY In BrowseTree, the playtrackalbum prefs would act on play, add, or insert when according to the description of the pref, it should only be on PLAY. This patch deals with fixing that part. for 6.1, perhaps, the safest path might be to reword to pref so that it refers to BrowseDB only, and disable this in BrowseTree until such time as it becomes less complex to compile a list of the objects in the folder (and excluding things like subfolders, etc)
Looks good to me.
just the patch, or do you want the rest of the idea too (pref desc, and disable in BrowseTree)?
Everything, if you feel up to it.
Created attachment 654 [details] patch to re-describe pref and disable for folders Then this would be the appropriate patch to disable playtrackalbum on folders. I've simply commented out the difficult code so that we can get back to it post 6.1. The strings will need new translations, I'm afraid. I can maybe guess for a few of them, and get Herger to take care of DE
play all from directory is disabled as part of change 3753. punting to post 6.1 for the right resolution.
*** Bug 1885 has been marked as a duplicate of this bug. ***
KDF - what's the right solution here?
I'm not sure. I suppose if the folder contents were added and the id's converted to objects lazily once added to now playing, that might work. I thought I caw something like this recently, in relation to another bug but I can't find it now for the life of me.
ah...it was 1824, and I thought it might have been working, but it isn't in my latest try.
Created attachment 763 [details] one example This re-enables the command from browseTree, but we still have th eproblem of the items after the listindex being just a filename. So, in this example, the playlist render will try what browseItemNAme does, converting to an object. You can see from the dumps included when you run this that it is extracting the objects and the render will show all tracks. This doesn't work, however, because as soom as the player mode changes, we lose topLevelPath AND the current playlist items fail to be converted to objects. This also doesn't save back into the current playlist, so it gets done at each render. its just an example, hacked up in the time I have. bed now. if I had the full solution, I'd be on it. I just dont know the best place to complete the conversion...maybe add the tracks up to listIndex...then add the rest one-by-one using the filename as some sort of findCriteria. Any solution could get really ugly for deep folder trees or lots of files in a folder.
Created attachment 856 [details] got it!!! a fix for bug2110 was a critical missing piece that I needed for this. Now, we can have this working for folder navigation. This patch reverts the strings to include folders. The operation in browseTree works by trapping ONLY the PLAY button and a list of items inside a folder. Any items that have already been scrolled are already objects, so there is a quick conversion to make the rest of the items into urls and passes them to the command module. The playlist render then makes them all into objects as needed and the playback starts on the selected song from the folder. testing with msg() and dumper, I can confirm that a list of just over 1000 items in a folder are converted to urls (leaving objects as objects) in about 260ms.
Nice. Go for it.
ok, committed to trunk, change 4427