Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: 7o9 on March 31, 2022, 05:35:41 AM
-
After recent commits that enable multi-boot (redirect) on x1000 players, I have compiled bootloaders for my Fiio m3k and Shanling Q1 and redirecting works.
My goal is to use the multi-boot/redirect functionality to be able to use 1 sd card in all my (supported) players and this works.
Both of these devices have no internal storage.
What happens though, is that when using the redirect functionality, the sd card gets named '<microSD0>' in Rockbox (i.e. the 'File' browser) and all content of the sd card is now relative to that '<microSD0>'.
Without the redirecting, my 'Playlists' directory is on the same level as the .rockbox directory.
With redirecting, Rockbox expects this in '<microSD0>/Playlists' which does not exist and gets created the first time you select 'Playlist Catalogue'.
When you move the sd card to a different device that also use redirection, you cannot see the 'Playlists' previously create as it is outside of what has now become '<microSD0>'.
Of course the contents of the playlists do not work anymore either because each path needs to have that '<microSD0>' prefix now.
Ideally, I think, on devices with no internal storage this '<microSD0>' would not be visible and the 'root' of the device would again be the actual root of the sd card. This would make it possible to share the playlists again between devices and also allow playlist management tools to make playlists without having to insert that '<microSD0>' prefix.
Possibly a similar argument would apply to the Rockbox database. Currently this is inside the .rockbox directory so for each device you would have to maintain the database individually.
Maybe an example helps to illustrate this:
SD card layout:
/rockbox_main.fiio_m3k (points to /.m3k)
/rockbox_main.shanling_q1 (points to /.q1)
/Playlists (my non-redirected playlist catalogue with paths without <microSD0>)
/.m3k
/.m3k/.rockbox
/.m3k/Playlists (created when first selecting 'Playlist Catalogue' on m3k, not accessible when using the Q1)
/.q1
/.q1/.rockbox
/.q1/Playlists (created when first selecting 'Playlist Catalogue' on Q1, not accessible when using the m3k)
/Music
On-device 'Files' (with redirect):
/<microSD0>
/<microSD0>/Playlists
/<microSD0>/Music
/Playlists (either /.m3k/Playlists or /.q1/Playlists)
On-device 'Files' (without redirect):
/Playlists
/Music
-
just an observation, hiding the root is a bad idea unless you are actually in the root otherwise you lose access to the 'real' root
better would probably be to go to the volume paths <0> <1> etc without the drive label
As far as I know the items you reference are endian corrected but its still something that needs consideration if/when you start sharing things unique to the device
-
I do not think I understand your first concern. What advantage does it have to show <microSD0> on a device with just one storage device?
My main concern right now is the playlist catalogue, which cannot be shared as it is in the redirected part.
I do not use the database myself right now, so that was only an observation.
PS: I edited my original post as my example was wrong. When using the redirect, all contents of the root of the sd card is under <microSD0> of course. Only the new 'Playlists' created by entering 'Playlist catalogue' is not.
-
I don't think it will matter with a single storage using the root -- until you redirect the root then you've effectively blocked yourself from the rest of the card
-
as far as the playlist catalog you could in theory redirect that as well but I don't think its important enough to the majority to mainline it
-
I figured out you can change the location of the playlist catalog from the context menu in the file browser -> Playlist Catalogue -> Set as playlist catalogue directory. The same can be done for the recordings directory. I've looked into making their default locations dynamic so they will appear in the volume root by default even with root redirect but it's more trouble than it's worth.
The drive label issue is a red herring since rockbox actually ignores the text when parsing paths, it only uses the number. As bilgus already mentioned using bare numbers like <0> and <1> works.
Provided that your playlists only refer to songs on the SD card it would be possible to use relative paths in playlists and have the playlist code interpret them relative to the filesystem where the playlist resides. (Relative paths are currently not supported as far as I know..?) I think that's about the best we can do, if the playlist tries to access files on a different volume it's going to be inherently non-portable.
Merging the volume root with the redirected root is bound to cause trouble IMHO. I don't like the added <microSD0> bit but it's the least bad option.
-
Thanks for both your replies, I appreciate your insights.
Being able to change the Playlist Catalogue directory to something on <microSD0> will make it easy to use the same playlists on all devices. I am going to try that. I have no intention to mix devices so that is fine.
Only handicap then is that I cannot make playlist files on my PC without having to add the <microSD0> manually, but that is fine.
I switch between my devices a lot so these developments are great. 6 of my 7 Rockboxed devices support this!
Edit: Using 'Start File Browser Here' on <microSD0> as well makes me almost forgot it is there. Only have to quickly edit my existing playlists and then all is good.