next »

[AEN007]

12September2011

Greetings.

I keep my mp3 collection in four places -
2 of them on 2 of my XP laptops.
The directory structure is the same everywhere -
only the drive letters vary ...
My m3u playlists look like this»

#EXTM3U
..\..\Oiu\v128\LvB-Sym#5¤I.mp3
..\..\Oiu\v128\LvB-Sym#6'Pastorale'¤I.mp3
..\..\Oiu\v128\LvB-Sym#9'Choral'¤IV.mp3

XMPlay won't open these relative path m3u files ...
but will open my relative path pls files ... like»

[playlist]
NumberOfEntries=3
File1=\Mu\OutM\Oiu\v128\LvB-Sym#5¤I.mp3
Title1=Allegro con brio
Length1=472
File2=\Mu\OutM\Oiu\v128\LvB-Sym#6'Pastorale'¤I.mp3
Title2=Allegro ma non troppo
Length2=723
File3=\Mu\OutM\Oiu\v128\LvB-Sym#9'Choral'¤IV.mp3
Title3=Presto > Allegro molto assai (Alla marcia) > Andante maestoso > Allegro energico, sempre ben marcato
Length3=1419

Every other multimedia/mp3 player I use will open
both/either of the relative path m3u & pls playlist files ...

Maybe XMPlay might fix this in a future release?

[Ian @ un4seen]

Relative paths should be supported in M3U playlists too (I just checked to confirm it). It looks like there are some funky characters in your example, so perhaps that is what it's having trouble with. What happens if you try a plain ASCII entry?

[AEN007]

30October2011

Greetings.
I never received an email notice of your reply.

I tried a "relative path" m3u playlist with only one entry & no funky characters,
but XMP gave the same result: the files in the m3u show in the XMP info/list with a line through them and will not play.
When I check properties of a "lined out" file in the XMP info/list,
XMP shows the correct path to file ...

So it is not the "funky characters" causing this problem.
In any case no other multimedia player has problems with my m3u lists, so why should XMP?
XMP handles the "funky characters" in the pls playlist with no problem ...

I have no idea what is causing this problem.

I need/want to mention another XMP "problem" with opening files.
I open/add files either by the XP contextmenu of a file explorer
or by the XMP "List - Add files/URL" action.
I created/use a shortcut/hotkey for that action.
When I execute the hotkey, XMP opens an "Open file(s)" popup.
After I select a file or just close the "Open file(s)" popup,
XMP always then opens an "Add files(s)" popup.

I have no idea why XMP does this, and
it seems to me XMP should not do this ...

[Pike84]

I need/want to mention another XMP "problem" with opening files.
I open/add files either by the XP contextmenu of a file explorer
or by the XMP "List - Add files/URL" action.
I created/use a shortcut/hotkey for that action.
When I execute the hotkey, XMP opens an "Open file(s)" popup.
After I select a file or just close the "Open file(s)" popup,
XMP always then opens an "Add files(s)" popup.

It sounds like you might have those two actions bound to the same hotkey. Check your shortcuts list and see if that's the case, and then either remove the "open files" entry or change the key to something else.

(It's potentially useful to be able to bind many actions to the same key... just in case you were wondering if this is how it's intended to work )

[Ian @ un4seen]

I tried a "relative path" m3u playlist with only one entry & no funky characters,
but XMP gave the same result: the files in the m3u show in the XMP info/list with a line through them and will not play.
When I check properties of a "lined out" file in the XMP info/list,
XMP shows the correct path to file ...

Is it a single or double red line that appears in the list? A double line indicates a file that can't be opened, while a single line indicates a file that can be opened but not played, eg. an unsupported format. If you add the MP3 files in another way (eg. drag'n'drop them), can XMPlay play them? If so, are their filenames/paths identical to the playlist-loaded files? You can enable "Show filenames in extended list" to quickly compare filenames, or use the "Track info" windows.

[AEN007]

31October2011
Greetings.

It sounds like you might have those two actions bound to the same hotkey.

... indeed (as I mentioned/posted elsewhere) I try (as much as possible) to "standardize" my multimedia (MM) hotkeys. I use a dozen or so freeware MM apps.
The WinAmp non-global (local) hotkeys are non-customizable and so are often the model I use for other MM local hotkeys. WA uses L for "add files" for the main GUI and for the playlist editor. I had the L hotkey for both actions in XMP. WA does not "double-fire" when L is executed. The main GUI hotkeys are only active when the main GUI is active and vice versa ...

maybe it should be the same with XMP? Just a thought ...
Do all XMP List shortcuts execute even when the List is not visible/active?
Do all XMP GUI shortcuts execute even when the List (not the GUI) is active?

Like I posted elsewhere, I would be nice if users could click on either of the shortcut column headings in the XMP options & stuff GUI to sort the view of the shortcuts ...

Thanks for the reply/solution in any case ...

[Dotpitch]

WA uses L for "add files" for the main GUI and for the playlist editor. I had the L hotkey for both actions in XMP. WA does not "double-fire" when L is executed. The main GUI hotkeys are only active when the main GUI is active and vice versa ...
maybe it should be the same with XMP? Just a thought ...

In XMPlay, the Playlist Panel (with the same functions and the Extended Playlist) is right in the Main Window, so you cannot make that distinction. Also, why would it be required to have the playlist visible to add files to it?

It would be nice if users could click on either of the shortcut column headings in the XMP options & stuff GUI to sort the view of the shortcuts ...

You can bind multiple actions to the same shortcut (as you found out). The actions are executed in the order in which they're found in the shortcut list. Sorting the list would alter the execution order and break the shortcut, so that's not going to happen.

[AEN007]

In XMPlay, the Playlist Panel (with the same functions and the Extended Playlist) is right in the Main Window, so you cannot make that distinction. Also, why would it be required to have the playlist visible to add files to it?

My point was not that the playlist GUI should be active/visible to add files to it.
With most multimedia apps the playlist hotkeys do not fire unless the playlist GUI is active.
But you say the playlist GUI is not separate a GUI from the main window GUI
- even if the list is not visible;
so the playlist is active whenever the main GUI is active even if the list is not visible, so ... whatever ... maybe future XMP "doc" might make that point ...

You can bind multiple actions to the same shortcut (as you found out). The actions are executed in the order in which they're found in the shortcut list. Sorting the list would alter the execution order and break the shortcut, so that's not going to happen.

My point is to sort the VIEW of the shortcuts in the GUI not the shortcut sort order in the registry/ini file.
I know very well how XMP stores the shortcuts in the ini file.
It could/would certainly be possible (and a worthwhile enhancement) to be able to sort the VIEW (not the storage order) of the shortcuts ... but whatever ...

[Pike84]

I agree that the shortcuts list isn't ideal, and I think there might be several ways to improve it. I've proposed something like this before, and it's been noted.

[AEN007]

Is it a single or double red line that appears in the list?
A double line indicates a file that can't be opened, while a single line indicates
a file that can be opened but not played, eg. an unsupported format.
If you add the MP3 files in another way (eg. drag'n'drop them), can XMPlay play them?
If so, are their filenames/paths identical to the playlist-loaded files?
You can enable "Show filenames in extended list" to quickly compare filenames,
or use the "Track info" windows.

It is a double red line.
Like I "said" previously,
- the XMP playlist Track Info "XMP shows the correct path to file ...";
- XMP will play these same mp3 files when I add/play them via a pls relative path playist;
- All other MM apps that I use will open/play these relative path m3u playlists with no problem;

The XMP track info "shows the correct path to file ..." and shows filetype "MP3"
but does not, however, read the track tags.

XMP will add/play these same mp3 files when I use a "full path" m3u playlist.

When I click "Scan for new locations" under Option &Stuff\Playlist\Dead,
XMP opens the browse folder window to the m3u folder/directory -
not the folder/directory for the mp3 files.
The folder/directory structure is:
%Drive%
 \Mu
  \OutM
   \3plm
     \m3u
     \pls
   \Oiu
     \v128
My m3u playlists look like this»

#EXTM3U
..\..\Oiu\v128\LvB-Sym#5¤I.mp3
..\..\Oiu\v128\LvB-Sym#6'Pastorale'¤I.mp3
..\..\Oiu\v128\LvB-Sym#9'Choral'¤IV.mp3

The double "..\" says go back 2 levels (to OutM) then find Oiu ...
All other MM apps that I use will open/play these relative path m3u playlists with no problem.

[Dotpitch]

Trying it here, going up one level from the m3u works (..\test.ogg), but two levels doesn't (..\..\test.ogg). Checking the path in Track info shows that XMPlay goes up three levels in that case, instead of two.

All other MM apps that I use will open/play these relative path m3u playlists with no problem.

It's a bug, no need to compare it with other players.

[Ian @ un4seen]

Trying it here, going up one level from the m3u works (..\test.ogg), but two levels doesn't (..\..\test.ogg). Checking the path in Track info shows that XMPlay goes up three levels in that case, instead of two.

Ah yes, I see that. Here's an update that should sort it...

   www.un4seen.com/stuff/xmplay.exe

[AEN007]

All other MM apps that I use will open/play these relative path m3u playlists with no problem.

It's a bug, no need to compare it with other players.

7November2011
Excuse me, but there was a need to make that statement, because
that condition was grounds for my concluding that the problem was with XMP ...

[Dotpitch]

Did the stuff version Ian posted fix the issue?

[AEN007]

10November2011

Greetings.

Does anyone know anything about XP SystemFileAssociations?
This week I have been doing some reg tweaking
to have XP use the SFA "text" settings for the contextmenu
for non-document text file that I classify as PerceivedType=text.
I have never used the SFA feature before.

Today I discovered that XP will not use the SFA "text" settings with m3u playlists.
XP does use the SFA "text" settings with pls playlists.
XP will seemingly only use the SFA "audio" settings with m3u playlists.

I am guessing there is something somewhere in the registry
telling XP to use only SFA "audio" settings with m3u (& mp3) files.
I thought XP was supposed use whatever PerceivedType was specified.
If someone wants .avi files to be PT=image, they should be able to do that.

Any helpful replies/insights appreciated ...

[hakerdefo]

Trying it here, going up one level from the m3u works (..\test.ogg), but two levels doesn't (..\..\test.ogg). Checking the path in Track info shows that XMPlay goes up three levels in that case, instead of two.

Ah yes, I see that. Here's an update that should sort it...

   www.un4seen.com/stuff/xmplay.exe

thanks a million ton Ian. This update fixed that nagging playlist problem  You are a genius