You are not logged in.
I use MPD playlists rather heavily, and noticed when I move files to a different location my MPD music_dir, their references in playlist are silently removed.
Is there a handy script floating around to do this, or can MPD or a mpd client do this for me?
Offline
To my knowledge there is not, at least I have never seen something like this. Apart from that it isn't even easily doable. For MPD the renamed file is a completely new file, so it doesn't know if the content is the same.
The way big audio players do that is by renaming the files themselves so they can track those. Renaming from outside is a pure guessing game.
So I think you need to make a script that does the actual renaming itself and monitors the playlist at the same time.
Last edited by Rasi (2018-04-29 05:52:59)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
So I think you need to make a script that does the actual renaming itself and monitors the playlist at the same time.
Thanks. I wrote the MPD fellas on their own forum, might get some more information there too.
Offline
This doesn't seem so hard.. Can you post the sqlite file somewhere?
// TODO fix this.
Offline
This doesn't seem so hard.. Can you post the sqlite file somewhere?
Actually it IS kind of hard to do this *properly*. Remember MPD does not necessarily run on the same machine, so the rename script has to run on the same machine as MPD. Which basically means it cannot be part of the client itself, since that most likely runs elsewhere.
Also not related, but MPD does not have a sqlite file. It uses a plain text library.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Actually it IS kind of hard to do this *properly*.Remember MPD does not necessarily run on the same machine, so the rename script has to run on the same machine as MPD
ok, my bad.. I don't know anything about MPD.. I just ran 'pacman -Si mpd' and I saw sqlite as a dependency.. Everything else was an assumption.
// TODO fix this.
Offline
Doesn't mpd store playlists simply as m3u files in playlists_directory? It shouldn't be too difficult to fix them up.
Edit: This java application seems to be designed for the task: http://listfix.sourceforge.net/
By the way, mpd will use sqlite, but only for "song stickers"
Last edited by progandy (2018-05-07 18:35:04)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Doesn't mpd store playlists simply as m3u files in playlists_directory? It shouldn't be too difficult to fix them up.
Edit: This java application seems to be designed for the task: http://listfix.sourceforge.net/
By the way, mpd will use sqlite, but only for "song stickers"
I don't think he means these playlists. He is rather talking about the queue (which most clients also call "playlist")
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Well, that would be state_file which is gzipped plaintext.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Well, that would be state_file which is gzipped plaintext.
First of all: The state file only contains information that clients already know about, aka the current status
of playback and queue.
But MPD only knows about the old filename. It has no way to detect that the new file is the same file as before.
Let me explain with an actual example:
MPD has a queue filled with tracks. lets say they are called A.mp3, B.mp3 and C.mp3.
Now the user renames A.mp3 to D.mp3 (and maybe even fixes the tags).
MPD will now delete A.mp3 from queue and finds a new song D.mp3 in its library. For MPD this is a completely new file.
Whinny now asks for this: MPD should automatically detect that D.mp3 and A.mp3 are indeed the same file and should automatically insert D.mp3 into the previous
position of the queue.
This simply is not possible for MPD clients, not even MPD itself knows that A.mp3 and D.mp3 are the same file. (With changed tags it infact is a new file).
But even without changed tags MPD would not know, because MPD does not keep track of any kind of checksum.
The only viable solution is that the program that does the actual renaming keeps track of the old/new files. Sure this feature could be integrated into some MPD client,
but it a) only works if the client has access to the actual music files and b) works outside of the MPD protocol.
Last edited by Rasi (2018-05-07 20:30:12)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline