Thorden wrote:"Tools"/"Extensions" says 3.5.3 is installed, but in the options it says v3.5.2
Milopita wrote:Is it possible to get playlists written that all of these players can read and understand? Will I need duplicates?
I am trying to create playlists that my Squeezebox can use and that I can see using TunesRemote+ connecting to MonkeyTunes and Logitech remote controller and a Squeezebox radio can see using Squeezebox.
I am using:
TunesRemote+ 2.4.1 and Logitech remote 1.1.1/r8350 on an HTC Desire (Android 2.2)
MediaMonkey 126.96.36.1998 and MonkeyTunes 188.8.131.52
Squeezebox Version: 7.5.1 - r30836 on a QNAP NAS TS-409 firmware version:3.3.2 Build 0918T
My music is stored on my QNAP NAS in this format:
\\NAS\Qmultimedia\MUSIC\Banco de Gaia\10 Years\18 - Banco De Gaia - Touching The Void.mp3Squeezebox is monitoring:
/Qmultimedia/MUSIC for musicCan somebody please explain to me how they have setup the options for "Export M3Us/Playlists for Child Nodes 3.5" in order to get the playlists working in:
/Qmultimedia/MUSIC/Playlists for playlists
MediaMonkey as well as MonkeyTunes and its associated remote control TunesRemote+A jpeg of your settings would be really helpful if you have a similar system to mine. Is it possible to get playlists written that all of these players can read and understand? Will I need duplicates? Thanks for your help in advance, I have done some experimenting and some playlists that I created seem to work but I am not sure I am doing things right.
Squeezebox and its associated remote control Logitech Squeezebox remote and its associated player Squeezebox radio
Jondar wrote:What I want to do is the following:
replace the "//SERVERNAME/<path_to_file>" with "smb://user:pass@SERVERNAME/<path_to_file>"
ZvezdanD wrote:I suppose that the Path of tracks stored in your database is not with the "/" but the "\". So, maybe you should try to replace the "\\SERVERNAME\" with "smb://user:pass@SERVERNAME/". The "Use Regular expressions ..." option should be turned off in that case, or you should escape each "\" character since it is reserved in Regex.
Jondar wrote:Checking MediaMonkey, the path does have the backslashes (\\), but the .m3u files created use the forwardslashes (//) -- which I'm assuming is due to having the "Unix .m3u file format checked"?
ZvezdanD wrote:However, the order of the replacement is important and it is like this:
1. "Replace paths in .mp3 files" "with", then
2. "Unix file format".
Because of that you need to use "\" in the "Replace paths" string, not matter if you have checked "Unix file format" or not. Actually, you could use "\" instead of "/" even in the "with" string and it would be replaced to "/" because the "Unix file format" replacement is executed in the second step.
Users browsing this forum: Yahoo [Bot] and 13 guests