This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#5338 - Insert Random Folders
Attached to Project:
Rockbox
Opened by Mike (Falco98) - Wednesday, 10 May 2006, 18:50 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Thursday, 29 June 2006, 05:58 GMT+2
Opened by Mike (Falco98) - Wednesday, 10 May 2006, 18:50 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Thursday, 29 June 2006, 05:58 GMT+2
|
DetailsI propose that the context-menu for folders (specifically those containing other folders) be given a new context-menu option similar to "insert shuffled", but in which only the folders are mixed up, and the tracks are left to play in-order (creating a "random CD" effect).
There are currently at least 3 other feature requests open for this general idea: one proposes that, in normal play, once a folder is completed, the "next track" be chosen from a randomly-selected folder. Another proposes a list of all playlists be kept, and one chosen at random. Yet another requests that the "next track" be chosen from a random "album" listing in TagCache. What I ask for here is fundamentally different, and IMHO would be easier to implement ('insert recursive folders' and 'insert shuffled' are already there, so there's plenty of example code to work with), and easier to test (just view the playlist generated, see how random it is, make sure it contains all subfolders, etc). Plus if anyone is really familiar with playlist.c, it may even be possible to do without having to create whole new functions. [working patch here: http://www.rockbox.org/tracker/?getfile=11854] |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Monday, 09 October 2006, 13:25 GMT+2
Reason for closing: Rejected
Additional comments about closing: random folder advance is in so this wont be accepted
Monday, 09 October 2006, 13:25 GMT+2
Reason for closing: Rejected
Additional comments about closing: random folder advance is in so this wont be accepted
as of right now i'm officially offering a $10 bounty (10 USD paid by Paypal) for a complete, working patch for this (to be used, at least, on my iriver h140). I will possibly consider a higher bounty (plus project donation) if it can get included in the official release, at least after 3.0 has been finished. PM me on the forums for more info.
it actually worked first go which is pretty amazing :D this is limited to 512 directories tho (32 on the archo's) but its good enough.. also its not really all that random
except i dont like how the found directories are stored so im redoing that little bit which is taking longer than i expected.. i guess coz im asleep...
ill hopefully get it completly finished tomorow (too bad this wont get added (if at all) untill after 3.0..)
as for the init time.. ye i know, if you dont have dircache on then this may be wa to slow to be usable.. im sure there is plenty of room for optimization tho so ill keep playing..
if i can get it fast enough to be really useable then ill try using this for jumpt to a random dir at end of current dir thingy
no more storing indicies of any sort.. and only a minor addition to the current add_directory_to_playlist function :D
drinks all round i tinhk.. (oh this version lets u add to an exsisting playlist... it _should_ only add after the current track, but thats not tested...)
here's the algo, approximately:
i = random() % num_of_tracks
if i >= (num_of_tracks / 2)
{
count UP to find next folder
}
else [if i < (num_of_tracks / 2)]
{
count DOWN to find next folder
}
easy!! and it starts working from even the 2nd folder added, the middle-cases should work fine, and it doesn't bias the beginning or end of the playlist too much. let me know if it seems like it'll work.
this is a new, and as far as i know, different problem. I'm thinking it might be a bug in its detection of folder boundaries or something like that. I'd try to debug the code myself but i'm still just a bit too confused by it :-/
i think this version is a bit simpler to follow.. but its randomness needs a bit of work..
lemme know what u tihnk...
i've implemented the cointoss, and already-playing case. i *think* i've sorted out the folder-split problem, though it could use some further testing.
issues:
-- normal "insert shuffled" (the included rockbox function) seems to be broken. i don't think it's in the playlist.c function itself, so check elsewhere.
-- something in what's written to the .playlist_control file is messing things up -- in the simulator at least -- for instance, if you do "insert tree randomly" (and it works), then stop, and try it again, it will NOT work. that might be something unique to the simulator tho, as i haven't had the problem (yet) on my h140. (i also haven't tried the latest code on it yet. too tired.)
specifically: i think it splits folders when the cointoss is going "-1".. i'm trying stuff now...
line 687 of playlist.c needs to be i++ regardless of direction because of how indexing works.
when it finds the folder boundaries, you have it do "i += direction; break;"
instead, it needs to do "if (direction = -1) i++; break"
it seems to work after several tests. i'll let ya know.
Jd: I've tested as much as I can in the sim, and will test for a bit in my 140, but as far as i can tell my fix worked (only one line of code too, heh). I also re-hardcoded the coinflip to only go "up" when already_playing, but i guess your way works too [though it seems to me that that way may overly increase the chances of things getting added "last"...]
Pastebin is down at the moment so i've put it here instead... careful, it expires after a day.
http://rafb.net/paste/results/KJlECJ99.html
you were correct the whole time about needing to do i++ if direction == -1.. so thats in the patch now for good...
as for hardcoding direction to 1 if playlist is started is not needed... just because it adds to the end if u get to the begginging doesnt mean it adds to the liklyhood that it will get added to the end.. in fact if u have it with the ability to goto -1 it decreases it.. even with that constraint... because the whole point of direction is for when it looks for a place to add the folder.. so you could be at the end of the playlist, but direction == -1 so it wont get added at the end which is perfectly acceptable if the playlist has started.
Here is an updated version of the previously-posted patch, in which the only thing changed is the "if( direction = -1 ) i++" thing. I included my line of code about direction-fixing, but it's commented out.
everyone test! let us know how it is. and if it works perfectly, enjoy!
this 1 is ready for as soon as the freeze finishes..
ah. damn. I guess when they fixed up some stuff in playlist, they broke the patch.
I know for a fact that it works perfectly with the source from 5-19, so try that out. I'm figuring JdGordon's latest one should work just fine with it. Meanwhile I'll try to figure out what got broken...
the earliest it can be accepted is like tuesday ro something (after the freeze closes) so i was gonna get it merged with the sources then so it works ok.. but whaterver...
big thanks, seriously.
thanks!