M3U format options [#6255]

[mcow]

I was looking at the list of remaining "urgent bugs" and noticed bug 6255, which has implementation of formatting options for the M3U files created by MM for portables.

I see that there is an option for Linux-style path separators. Does this option include Linux-style line-endings? I use Canola on my Nokia tablet, and Canola insists that M3U files must end with only LF, no CR. The Export M3U add-on script makes both changes on a single option, which works for me and probably would work for anyone; I can't imagine that an M3U with '/' separators would choke on LF-only line-ends.

It isn't clear to me why that bug was still open, but as long as it is, I thought I'd throw this out. I'm not running MM4 at this time, so I can't check it myself.

[jiri]

Looks like a good suggestion, we'll try to implement it.

Jiri

[rusty]

Fixed in build 1407. Please confirm that it works for you.

Thanks.

-Rusty

[markstuartwalker]

I realise that I've come to this a little late, sorry. I've already used the '/' separator and relative paths options quite successfully already thank you.

There are two further enhancements that I would like to see ....

1. validate file paths. Like all windows programs MM doesn't care about case in it's file paths but Unix systems do. It's quite possible to rename a folder outside of the MM programme after MM has read the file in (say to add a capital letter prefix). This means that the path that MM exports is actually wrong. It would be good at m3u file creation that the correct file paths be substituted. I've got a bit of Delphi code from my symlink driver that does this if you'd like it.

2. Substitute path content. Absolute file paths in Windows and Unix are different as Windows uses drive letters and Unix uses the mount points. For players that need an absolute path you could build a substitute from->to list to change the drive letters into mount points.

[markstuartwalker]

Code: Select all

function verifyPathCaseSensitivity(path:WideString):WideString;
var
  j,k:integer;
  folder,validPath:WideString;
  folders,subfolders:TStringList;
begin
  folders:=SplitStringToList(path,'\');

  validPath:=folders[0];
  for j := 1 to folders.count -1  do
  begin
    // get a list of the sub fodlers
    subFolders:=filesAndFoldersOf(validPath);
    subfolders.CaseSensitive := false ;

    // find the sub folder case insensitively
    folder:=folders[j];
    k:=subfolders.IndexOf(folder);
    if k>=0 then
    begin
      // append the valid folder
      validPath:=IncludeTrailingPathDelimiter(validPath)+subfolders[k];
    end;
  end;

  // give back the answer
  result:=validPath;

end;

[mcow]

Fixed in build 1407. Please confirm that it works for you.

Thanks.

-Rusty

I have been trying to confirm with build 1408 and I cannot get the M3Us to be created at all.
My device options:
[x] sync playlists
Generate device Playlists for
[x] Albums
Dest directory: \Music\
[ ] Organize playlists...
[x] Force relative paths
[x] Use Unicode
[x] Use extended M3U
[x] Use Linux separator

Syncing to a Nokia N800 tablet, which is configured as a USBMass1 device. Music syncs fine.

[Lowlander]

Try again with 1412 which is the current build.

[mcow]

I discovered that a single, empty playlist was created (altho three albums were sync'd over), but it was called
N800 (N-).m3u -- apparently named for the device, not for the album(s) as my options were set up.

Try again with 1412 which is the current build.

Not unless you can point me to a bug marked Fixed since 1408 that looks at all related to on-device playlist creation. I have better things to do than play russian roulette with random beta builds.

[Lowlander]

I have better things to do than play russian roulette with random beta builds.

The same goes for chasing bug reports on old builds.

[mcow]

You seem to think that bugs can be magically fixed by an incremented version number.

I experimented some more with the options, and the part that's not working is the "Generate playlists for..." settings -- only the "Library Playlists" option works. Real easy to test, no chasing involved -- especially since the playlists are re-generated, if missing, each time the Sync button is pressed, even if the music files are already resident on the target device.

The Linux path separator feature does indeed use the Linux line ending, which is what I initially set out to check.

[Lowlander]

You seem to think that bugs can be magically fixed by an incremented version number.

There have been plenty of times were users reported bugs and upgrading to the newest build fixed it. Add to that, that not all fixes that happen are reported in Mantis. Anyway when reporting bugs the latest version should be used to make sure no old ghosts are chased for nothing.

1) Make sure that you're using the most recent build

from: http://www.mediamonkey.com/forum/viewto ... ?f=6&t=341

In this case a debug log send to support might be the best route.

[mcow]

Another M3U option that I will need to use the playlist-creation feature is to write the UTF-8 files without the BOM. I've discovered that Canola won't read a BOM'd file, just as it won't read a file with CRLF line endings.

What a pain. I probably should just get an iPod. Someday.

I also note that the current (well, as of 1408) implementation of "extended M3U" doesn't do anything except put a #EXTM3U header in the file. This doesn't make any difference to me—Canola accepts EXTM3U but doesn't use the features—but without the #EXTINF's, there doesn't seem to be much point.

EDIT: 29-Jul-2011
The File | Export to Playlist command, using UTF-8, also includes the BOM. (This is much better behaved than the MM3 implementation.) I took one and made a copy without a BOM, and then loaded both into WinAmp. WinAmp requires the BOM; the M3U without the BOM resulted in unintelligible entries in the playlist, and the associated files were not found.

It'd be great if the BOM were optional, but I've written a simple conversion script that I can run on the N800 after the playlists have been copied over. After some research, I think I've determined the problem is Nokia's fault: Maemo mandated UTF8-no-BOM as the text format, and didn't support BOM until Maemo5.

[Ludek]

Fixed in build 1407. Please confirm that it works for you.

Thanks.

-Rusty

I have been trying to confirm with build 1408 and I cannot get the M3Us to be created at all.
My device options:
[x] sync playlists
Generate device Playlists for
[x] Albums
Dest directory: \Music\
[ ] Organize playlists...
[x] Force relative paths
[x] Use Unicode
[x] Use extended M3U
[x] Use Linux separator

Syncing to a Nokia N800 tablet, which is configured as a USBMass1 device. Music syncs fine.

Thank you, you are right, this no longer works, fixed as: http://www.ventismedia.com/mantis/view.php?id=8205

[mcow]

Thank you, you are right, this no longer works, fixed as: http://www.ventismedia.com/mantis/view.php?id=8205

Not working for me with build 1415. Of these options:
Generate playlists for:
[x] Library Playlists
[x] Artists
[x] Albums
[x] Location
only Library Playlists works.

[rusty]

Tested 1420 and the m3u format options are all working for me. I tested both wmdm and usbms plugins, and tested with 'Organize playlists using...' both enabled and disabled.

Is the problem always occurring for you with the latest build? Perhaps a debug log?

Thanks.

-Rusty