Issue with playlists when path has changed

Roon Software Discussion
1

Hi all,

This is apparently an old issue - there’s an old post from 2018 highlighting this - but apparently never solved. Somehow when changing the path of a folder, this is not reflected in the m3u file when exporting a playlist.

Today, I imported a few albums into Roon, and added songs to existing playlists. I then realised that the albums folders’ names had the bitrate information in them, I don’t like that, so I edited those names. I then exported the playlists for my Sony Walkman.

Those playlists all turned out to be empty on the Sony Walkman, and after checking, it turned out the exported playlists had the path for the folders with the bitrate at the end of each album’s name, and were thus incorrect.

So for example the playlist gives this path:
…/The Black Angels/Passover (16B-44.1kHz)/1-01 Young Men Dead.flac
But the actual path is:
…/The Black Angels/Passover/1-01 Young Men Dead.flac

I am not sure how this happens. Deleting the playlists and recreating them again does nothing. Somehow, somewhere in Roon the initial path is stored, and while Roon has no problems finding the files and playing them after the change, every time it exports the actual path it’s the old one. Restarting Roon does not help and neither does rescanning the library.

Removing the album and putting it back does not work either. In fact, I even tried to change the name of the folder again before putting it back. I EVEN tried to move the album folder into another location, still visible to Roon: that initial path just seems to be sticking to those files!

I actually realize I’ve had issue in the past with some songs not showing up in exported playlists, and I now suspect it was a similar issue. Playlists are really not getting a lot of love in Roon, I hope this can be sorted out at some point. I understand Roon does not like to deal with files structures, but it shouldn’t export a completely wrong path…

2

Potentially dumb question: did you perform a Library cleanup?

2 Likes
3

Yeah. Had some files to delete, but it did not change anything.

4

Have you tried manually editing the .m3u files externally?

If not, and if you think that might help by getting those paths correct, I have a pretty detailed set of steps for this which I’m happy to post here and/or share with you to try and help.

I use the Numbers spreadsheet on a Mac, but assume it could be done with Excel.

5

I mean, sure, of course I can do that. But that’s not quite the point if I may: it would mean I would have to remember and go through the process of manually correcting the paths whenever any song of any of those albums is used in an exported playlist. That’s hardly practical beyond a one-off.

Unless I misunderstood something? Not sure why I’d use excel for this, TextEdit is a much more appropriate tool, so maybe you didn’t mean editing the m3u itself?

6

Albert-Phlip,

Of course. I don’t want to complicate or confuse things. So stop me if I’m failing to understand. I’m taking my cue from:

So I’m imagining that you may have one of two options:

  1. not change the path to/location of the folder
  2. if you do that, edit the .m3u file to accommodate the change.
    When you say…

You do mean the folder in which the music itself resides, and not the one where the Playlist is, don’t you?

Both are in your Roon watched folder, aren’t they?

I would expect Roon to cope with (music) Album folders being moved.

But I wouldn’t think it could go into the text strings of any .m3u file - particularly when you remember that a Playlist which you create entirely inside Roon is handled differently from one you build yourself, as seems to amount to being the case, doesn’t it - given the export-Walkman-import process.

I did learn that it’s often necessary (and actually quite easy) to edit those .m3u files in order to get Roon to find the Albums again.

I believe - others will correct me if I’m wrong - that that might indeed actually be the case with Playlists you build or manipulate yourself. @DDPS was extremely helpful in that thread, where you might find much useful information and directions from the experts.

No, you did understand, Albert-Philip: a spreadsheet because it retains columns and you can more easily make bulk changes - if even to the path string portion of each of the .m3u’s lines - in one fell swoop.

So in the example I built/edited for the Beethoven-Brendel (which I’d be happy to send you in case it might serve as a useful template) a single edit to Column A was all that was needed to fix it.

7

Thanks for clarifying.

To be clear on my side: I am talking about a playlist created in Roon, and exported using the standard export to folder function. This seems to be a database issue first and foremost: the files have been moved but are still in a folder visible by Roon, I can see them there and play them without issue. But when exporting, somehow, it writes down the old paths in the m3u.

So I can modify the m3u by hand and get it to work, but that’s not the issue. Note that the formatting of the paths is not a problem, Sony software recognises Roon formatting here without problem (it still requires some m3u tags I have to add manually).

1 Like
8

Thanks to you for clarifying, Albert-Philip!

You’re saying that the very act of exporting may itself be corrupting or otherwise compromising some part or parts of the playlist files, aren’t you?

I can only imagine that we shouldn’t expect Roon to open the .m3u files and change the path string before exporting.

That has never been my experience: quite the opposite.

So, I agree, it would be good to know what could be going on during the export process; and how, and why.

Happy to help if I can. Good luck investigating further :blush: .

1 Like
9

Not quite. I think the act of exporting shows me something is wrong in the database, and I would not see it otherwise.

I literally just removed the bitrate info in the folder’s name in Finder. So:
Passover (16B-44.1kHz) is now Passover. But Roon keeps exporting Passover (16B-44.1kHz).

I am testing some more as I’m writing this, and I realise the issue is worst than I thought: it will use Passover (16B-44.1kHz) every time it exports not just in the m3u, but as the name for the folder, so I guess it thinks all is good (I don’t use the exported files, I just have a copy of my music collection on my player, so the paths now don’t match). I guess it’s time for a bug report and support request!

2 Likes
10

You changed the actual folder name on the storage disk? Is the storage disk on a NAS?
Have you restarted the RoonServer which will initiate a rescan?

1 Like
11

I actually found the issue and solution in another thread, but I guess I should also post it here for other people having this problem:

It turns out Roon was not exporting the old path name. Instead, it was exporting the folder name as the album name with the version field appended. The version field contains that bit rate. It just so happened the old name and the new name with the version appended were exactly the same in my case (I’d assume that’s pretty rare!). With the export function not being described in any details anywhere, it took some playing around to figure this out.

This never happened to me before, and I do not know what changed. I buy most of my albums on Qobuz, and before the last few imports, all have a blank version field, so Roon wouldn’t append anything to the album name. Did Qobuz start filling in this info? Did Roon start filling this field automatically?

In any case, one of the solutions is to simply mass edit and make sure the field version is blank. If you do want that field to contain data, then I don’t know how you can avoid the folder name to be modified by Roon.

Should you be confused by the explanation, here is an example:
Say you have an album name of Passover, artist The Black Angels, and the version field contains 16B-44.1kHz, the album will be exported as:
…/The Black Angels/Passover (16B-44.1kHz)

1 Like