XMPlay - audio player

[lautrepay]

It is not a matter of "big indignity", but the need of ensuring consistency between the database entries.
For years XMPlay had a public entrey on this site and, if you read the comments, you'll see that the users were very, very satisfied with the application, with very little complains regarding problems with the library path.
But then, after the release of the PortableApps.com version, the program is suddenly so broken that its native portability does not even deserve a mention? It is not coherent.
I still think that the library function is a secondary one, and we should follow with what have been the rule: the natively portable application with the main spot, and the portabilized versions listed as alternatives.
If not, we will have to start a purge in the database, and the first candidate is Process Explorer, an all time favorite of TPFC users: it's not stealth, not even portable. Why not just drop it out in favor of the PortableApps.com Version, that keeps the settings and is stealth?

[Midas]

@lautrepay: excellent points -- although I have no easy answers...

[webfork]

I think the primary reason NOT to use PortableApps programs is that we don't want to just duplicate the PortableApps website here. That's a rationale SYSTEM made a while back on the "What to list first and why" thread and I still think it makes sense. The reason to list a PA program where there's a native alternative is usually one of two reasons:

1. Lack of involvement/interest (it's what got added first, nobody feels like changing it)
2. When the main program is broken, as with the VLC situation (viewtopic.php?t=7519).

Stealth status generally doesn't affect the native version getting primary status. If VLC ever brings back portable functionality (or XMPlay fixes the path/drive portability issue), I'll happily switch it back.

the program is suddenly so broken that its native portability does not even deserve a mention? ... if you read the comments, you'll see that the users were very, very satisfied with the application, with very little complains regarding problems with the library path.

I left it off for two reasons:

• Nobody seemed to care.
• When I list the native version, it's going to be with the disclaimer like "no drive letter/path portability" right next to the PA version "fixes drive letter/path portabiltiy". Most users that don't have feelings about PA already will likely go with the former.

That said, having had several minor problems with PA programs since then, I'm definitely fine with including the native version as the alternative.

we will have to start a purge in the database, and the first candidate is Process Explorer

I also want to ensure consistency among database entries for Process Explorer (if it's portability really is broken -- I haven't looked at it) or any other program. What I'm saying here is that this does follow a protocol. If I do this one differently, then that marks a policy change. It's one I disagree with but if that's what the site wants, that's what I'll do from now on.

[webfork]

I'm definitely fine with including the native version as the alternative.

Whatever's decided here, I just added the native XMPlay version.

[DarkShadow]

If it's the PAs version, why does the db entry say "path portability: no" ?

[SYSTEM]

If it's the PAs version, why does the db entry say "path portability: no" ?

Good catch. I changed it to "Automatic relative path".

[joby_toss]

22 Dec 2015
XMPlay 3.8.2 released

Adds support for HLS (HTTP Live Streaming) streams, RF64 files, and large (over 4GB) files.

[Checker]

@joby_toss: Cool, thanks

I like the new way the 'skin-selection' is organized now.

[Midas]

@webfork: given the fact that this is the official forum topic for XMPlay, I kindly request the removal of version info from OP. Plus the appropriate season greetings.

[webfork]

@webfork: given the fact that this is the official forum topic for XMPlay, I kindly request the removal of version info from OP. Plus the appropriate season greetings.

All set, thanks

[freakazoid]

XMPlay 3.8.5 should now support relative file paths in playlists.

Haven't tested the library yet, but if the library is now relative, then native XMPlay could replace the PA.com version.

[Midas]

FWIW, XMPlay is still at v3.8.5 released 2020-09-02...

This post is just to add quick links to the official release announcement and "stuff" (history?):

• https://support.xmplay.com/files_view.php?file_id=685

• https://support.xmplay.com/article.php?id=121 (stops at v3.8.2.9...)

• http://support.xmplay.com/article.php?id=109 (links to above...)