Author Topic: Musicbee's m3u & xml encoding - should be UTF-8 (Without BOM) (imo)  (Read 5754 times)

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Hiya,
from the GUI thread re playlists - http://getmusicbee.com/forum/index.php?topic=15050.msg107269#msg107269
as its separate bug thead as the above is ginormeous...

iTunes Library.xml should be encoded as UTF-8 (Without BOM), as is, MusicBee's exported xml is encoded as UTF-8 With BOM - which is fine for some programs (Serato & Rekordbox I have tested and they can deal with this...), but one of my target programs (Traktor Scratch / Pro 2) takes offense to that encoding.
So the argument to go with UTF-8 (Without BOM) over UTF-8 With BOM would be that  iTunes natively exports as UTF-8 (Without BOM) as well for me.
But, might be there's opposite cases with other programs relying on the xml in UTF-8 With BOM despite Apple's own encoding being UTF-8 (Without BOM)...

Churs.
c.
Last Edit: July 13, 2017, 01:22:55 AM by alec.tron

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Same with m3u playlist files exported from Musicbee btw, which can't be imported into other programs unless encoding is changed from "UTF-8 With BOM" to UTF-8 (Without BOM) (imo).
Cheers.
c.

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Hai!
Any chance the itunes/m3u playlist encoding format (i.e. UTF-8 with BOM / UTF-8 Without BOM) could become a little user adjustable preference-setting inside of MusicBee now that v3 is released ? [Congrats btw! & thanks for all the work from everyone!]

And, while on the iTunes.xml topic - it would be really great to get some info if enabling playlist export to iTunes.xml is in the cards, or if this falls into the realm of no-fix / low-priority ? i.e. it's been discussed here but never got anything official:
http://getmusicbee.com/forum/index.php?topic=15165.msg106668

Cheers.
c.

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Bump.
This is still an issue for me when trying to use MB generated playlists in other programs.
Also, seeing there's 3 pages of search results on 'UTF' formatting - it would be great if the more tech savy users had some form of setting available to adjust this to what users need in this regard!

Any chance this is a feature that's easily added...?
I don't mind if it was just a setting somewhere in a xml/ini file to set encoding for all outbound formats (and maybe tag/metadata formatting, as that seems to come up a fair few times as well on the search)...
At this point, I'd take anything to get rid of the inbetween conversion step that's necessary atm as I do need all .m3us to be written in UTF-8 and not UTF-8 (with BOM).

Might be there's reasons to offer UTF-8 (with BOM) only in MB ? But generally, 'with BOM', even among programmers, seems to be the less desirable choice ?
See
https://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom

Churs.
c.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
for the next v3.1 update it no longer will write the BOM.
Its already the case for the exported iTunes file



alec.tron

  • Sr. Member
  • ****
  • Posts: 752
After testing - looks like a small bug snuck in on the last versions (3.1.6405 here). Hopefully it's not tied to the new non-BOM formatting ;)

Looks like replacing missing files in playlists is not treated as an edit anymore and does not get saved for some reason. i.e. I had a file in a playlist, which has been renamed since in both filePath as well as fileName, which I tried to fix in MB as I often do/did, but the replaced file now never sticks and when I close/re-open MB, the playlists, after close/open goes back to hold the old/missing file path and the file-system's edit time of the playlist in question is not updated either, so looks like something is stopping this from being detected as an edit or written out accordingly.

On the other side, file add/remove to a playlist does get saved as it always has and should.


I had a look at the error log as well, but nothing of note to report from there neither.

Churs.
c.
Last Edit: July 15, 2017, 11:53:18 PM by alec.tron

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Bump - not sure if I should make a bug thread for this or if you saw this @ Steven ?

Also interesting: the edit - swapping a missing file for an existing file - doesn't even survive switching playlists (i.e. fix a missing track in PlaylistA, then select PlaylistB to refresh the view for that, then go back to PlaylistA & the missing track URL fix is gone and it seemingly reloaded the playlists from scratch with the track missing again).
Then I thought I might be able to trick it - i.e. after fixing the missing track, select a track in the same playlist and send it to itself  / the same playlist again, which from what I saw in the past triggers a .m3u write immediately. Funnily enough, if doing that, the corrected / previously missing track gets switched back to be the missing URL right on 'send to playlist' execution, so that's a no go either.

Guess I'll go back to the previous patch I have saved (from 17_06_20) in the meantime.

Churs.
c.

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Heh. Nevermind, found the culprit, will post in a bit...


ps. So turns out, as the above behaviour surprised me a bit, that I had 2 playlists called 'WIP' in very different folder hierachies for different needs, as well as a static playlist folder called 'WIP' elsewhere, as well as a 'WIP' folder for smart playlist, and Musicbee did not like that at all... hence playlist edits being more than a bit erratic - funny though as some of them WIP named pieces have been around for a long time - I think I recently renamed the folder holding smart playlists to WIP, which might have been the straw that broke the camel's back...


Since Musicbee seems to be relying on unique names when it comes to playlists & folders, would be great if there was a warning when non-unique playlist/folder names are detected !
(in my extreme case that might be a bit tricky as I do rarely but occasionally do extreme edits to the organizational structure in file system directly as well, and let MB just read the resulting folder/m3u hierarchies... )
As well as throwing an error when a playlist can not be written (ideally with some indication as to why it failed).

Also, an interesting side anecdote... somehow, this whole case of non unique names for folders & playlists in MB also changed:
Preferences -> Library - playlists - exported playlists [ ... ]
path, which used to be:
Playlists_StaticExport\ (= *\MusicBee\Library\Playlists_StaticExport\)
and suddenly, while attempting to fix the multiple occurences of WIP names... I saw MB writing out all AutoPlaylists to new location, which was:
 *Playlists\WIP\ ( = *\MusicBee\Library\Playlists\WIP\)
all of a sudden, without me changing it in the preferences...
('library playlists' is set to 'Playlists\', which remained unchanged)

Oddity galore :D

Churs.
c.
Last Edit: July 17, 2017, 10:08:09 PM by alec.tron

ralfiii

  • Newbie
  • *
  • Posts: 7
I found this old thread any just want to refer to my post
https://getmusicbee.com/forum/index.php?topic=29470.msg164251#msg164251

It seems some programs like PowerAmp or WinAmp require encoding with BOM.

So making the BOM an option one can activate would help here a lot!
Last Edit: August 28, 2019, 09:30:57 AM by ralfiii