INTERACT FORUM
More => Old Versions => JRiver Media Center 27 for Windows => Topic started by: womble on September 30, 2020, 09:08:16 am
-
Hi,
While this is a great improvement, unfortunately it still doesn't get playlists loaded on Android 10.
The relative path needs to be relative to where the playlist is located so typically it would have ./../Music at the start not /Music.
If I add the ./.. to the start and copy the playlist back it loads without issue.
The actual prefix/relative path would need to be based on the file paths configured for that handhold.
-
I just ran a quick sync to a hard drive location and MC did add the "../" prefix to the Playlist, as below.
../Pendulum/Hold Your Colour/13 - Another Planet.flac
../Pendulum/Hold Your Colour/14 - Still Grey.flac
But it didn't add the leading "./" to specify starting in the current directory. Maybe that is needed in Android 10. I didn't check syncing to an actual Android device.
Selection of the format almost needs a dialogue of its own these days:
File Format
Relative Paths
Leading Dot
Forward Slashes
Full Paths
Without Drive Letter
-
Yes I was thinking that a M3U format which could have a expression in it as the filename could be a possible solution.
I am syncing to the SD Card location which shows up a separate device. The audio path is "Music\[Album Artist (auto)]\[Album]\" (note no leading slash) and the Playlist path is "Playlists\"
When I sync, I get the following:
/Music/(Multiple Artists)/The Rolling Stone Magazines 500 Greatest Songs Of All Time/89 - California Dreamin'.mp3
/Music/(Multiple Artists)/The Psychedelic Years Revisited, 1966-1969/205 - I Can Take You To The Sun.mp3
/Music/(Multiple Artists)/The Rolling Stone Magazines 500 Greatest Songs Of All Time/174 - Paint It Black.mp3
/Music/(Multiple Artists)/The Rolling Stone Magazines 500 Greatest Songs Of All Time/198 - Hey Joe.mp3
So the relative path is against the device but that is actually not a valid android path so the playlist is invalid. It makes sense when mounted via Windows (as the SD Card is a separate device) but doesn't make sense to android.
The relative path really needs to be relative to the location of the playlist file. Hence why the ./../Music/xxxx works.
IMHO either:
1. "M3U (android format)" which does the relative path relative tot he playlist location which can be determined from the file path options
OR
2. "M3U (expression format)" which allows an expression to create the filename to be written into the playlist. In my case it would be "./../Music/[Album Artist (auto)]/[Album]/" or maybe "./../Music/[Album Artist (auto)]/[Album]/[Filename (name)]"
-
I tried a sync to the microSD card in my Android 9 phone connected via USB, which Windows sees as a drive but MC sees as an Android device, based on the way it handles sync.
I got the same result as you. Playlists didn't have any leading dots, but included a leading forward slash.
/Music/Pendulum/Hold Your Colour/01 - Prelude.flac
The Playlists using the above paths work in my Sony Music App regardless, without having leading dots. But paths such as above are Absolute Paths, not Relative Paths, so I agree the functionality isn't working as intended.
Part of the problem is that before Android 10 forward and backward slashes are recognised. So maybe there isn't one universal "Android Format" that could be used for all versions, past, present, and future. Forward slashes should always work for Android, but who knows, without testing.
An expression format would be problematic, because then a user could specify an expression that didnt' match where MC actually put the files, using the existing settings. It is really just the first part of the path that needs to be adjusted.
Besides all that, I'm still getting errors with re-sync, incorrect file names on re-sync, files already on the device being put In Queue, and "M3U (relative paths)" isn't putting leading dots "./.." in the Playlist paths for Android anyway. It would be nice if all that was fixed as well.
PS: My Audio Path and Playlist Path settings are the same as yours in Handheld Sync Options. So MC is working the same for Android 9 and 10 by the look of it.
-
I just tried using forward slashes in the settings, and that broke the sync functionality completely. I think I have read about that before.
I also noted that the paths shown in the JRInfo.xml file on the Android device are all using backslashes, which may be contributing to problems. But MC uses backslashes in all the Sync displays anyway, so I assume it reads and interprets those files correctly regardless.
-
"An expression format would be problematic, because then a user could specify an expression that didnt' match where MC actually put the files, using the existing settings. It is really just the first part of the path that needs to be adjusted."
I think that is a reasonable thing, you gain the flexibility at the expense of the ability to stuff something up. You could say the same about any of the expression based features( like renaming files).
Expression based would probably be the quickest way home with the flexibility as new use-cases become apparent
-
This is the format that works on my LG V60 and every other device I have tried it on.
../Albums/Rock/The Police/The Police - Every Breath You Take The Classics/ 02 - The Police - Can't Stand Losing You.flac
My playlist folder and Albums folder are in the same directory.
-
This is a long thread, but next build we'll try this:
Changed: When building playlists for a handheld using relative paths, if nothing is in common, it will use dots in the path to start at the root then build the path (may make Android devices work better).
We didn't find anything in common on my Android between the Playlists\ path and Music\ path where the files were so didn't use relative at all. I changed it so it uses ..\.. to walk up, then go down again.
Let us know how it works once it ships. Thanks.
-
Hi Matt,
I finally have had some time to look at this.
It looks like the file path has the ../ in front which is good.
However the playlist files seem to be created with a .m3u.dup0 extension (actually .m3u.dupN where N can be a number) so they aren't being read by any application.
Is it MC that is applying that extension or something else?
Thanks
Russell