next »

[Elrinth]

@saga: hang on, I'm installing winamp atm.

The following songs would not open in xmplay for me, they do however open in VLC:
http://dl.dropbox.com/u/5145312/can%27t%20open%20in%20xmplay%20but%20in%20vlc/gold%20runner%20theme.mod
http://dl.dropbox.com/u/5145312/can%27t%20open%20in%20xmplay%20but%20in%20vlc/great%20commandment.mod
http://dl.dropbox.com/u/5145312/can%27t%20open%20in%20xmplay%20but%20in%20vlc/green%20sleeves.mod
http://dl.dropbox.com/u/5145312/can%27t%20open%20in%20xmplay%20but%20in%20vlc/into%20battle.mod
http://dl.dropbox.com/u/5145312/can%27t%20open%20in%20xmplay%20but%20in%20vlc/last%20ninja%20remix.mod

Edit:

Regarding previous post... Yes the same happens with winamp, however winamp crashes instead of it just becoming silent. (The plugin is crashing)
Then I'm asking, is there an option somewhere to recover/reinitialize plugins if they crash? Or maybe a specific plugin? in_ym *caugh caugh

[saga]

You should first mail the author (and pray that he's still developing it) that he should fix his plugin instead of finding workarounds...

[Zarggg]

If the plugin is crashing in both XMPlay and Winamp, the problem is likely with the plugin.

[Ian @ un4seen]

yes XMPlay successfully opens that URL for me (http://www.pigradio.com/pig128.pls)

but not this one

http://streamwriter.org/en/streamdb/getplaylist/list.m3u?id=2007

now if I open that URL first with the web browser then open the m3u/pls with XMPlay it opens and starts streaming

Here's an update to try, which should detect that it is a playlist...

   www.un4seen.com/stuff/xmplay.exe

[bamf]

it still doesn't detect the playlist when opened from the commandline/DDE call from streamWriter or whatever.  it DOES work when the playlist is opened from the open URL in the Open file(s) dialogue, however."C:\Program Files\XMPlay\xmplay.exe" "http://streamwriter.org/en/streamdb/getplaylist/list.m3u?id=2007"
worked
"C:\Program Files\XMPlay\xmplay.exe" http://streamwriter.org/en/streamdb/getplaylist/list.m3u?id=2007
didn't work (no quotes)hold on now its working with both commandlines. i just can't get it to work from the other program.

here's a screenshot of what happens when stream is launched
http://img854.imageshack.us/img854/8707/14261222.png

[Ian @ un4seen]

That sounds strange. If you right-click on the playlist entry and select "Track info", what URL do you see there and how does it compare in the working instance?

[amit]

If playback is paused, pressing the apply button in output settings and devices settings will resume playback.

[saga]

I have encountered a weird crash in xmplay 3.6.0.40, while i was doing an accidental mouse action (something like dragging over the xmplay with left mouse button pressed, i don't remember exactly). anyway, i've uploaded a minidump (saga-xmplay.dmp.7z) to your FTP, if it's of any help. I can also upload a mini dump with the heap included if it's necessary.

[bamf]

That sounds strange. If you right-click on the playlist entry and select "Track info", what URL do you see there and how does it compare in the working instance?

There are some differences in the track info, here are the screenshots of what's going on:



fig a. track info after opening stream


fig b. track info after pasting URL from previous track info into the open URL dialogue

[Ian @ un4seen]

I have encountered a weird crash in xmplay 3.6.0.40, while i was doing an accidental mouse action (something like dragging over the xmplay with left mouse button pressed, i don't remember exactly). anyway, i've uploaded a minidump (saga-xmplay.dmp.7z) to your FTP, if it's of any help. I can also upload a mini dump with the heap included if it's necessary.

It appears to have crashed while refreshing the playlist panel. For some more info on what went wrong, please do upload the dump file with the heap included.

There are some differences in the track info, here are the screenshots of what's going on:
...

That looks like the playlist wasn't processed in the "fig a" case, ie. the playlist file itself (rather than its contents) was added to XMPlay's list. Do you know how the URL was passed to XMPlay in that instance, eg. was it via the command-line or DDE or OLE? What happens if you drag'n'drop the URL (eg. the links you posted earlier) into XMPlay?

[saga]

It appears to have crashed while refreshing the playlist panel. For some more info on what went wrong, please do upload the dump file with the heap included.

Ok, minidump with heap has been uploaded (saga-xmplay.7z).

[Ian @ un4seen]

Ok, minidump with heap has been uploaded (saga-xmplay.7z).

Thanks. I'm not entirely sure how it happened, but it appears that the playlist panel's display index (which determines the entries that are displayed) somehow became negative, resulting in a crash as it tried to display a negative playlist entry. Here's an update with a safety check that will hopefully prevent it happening again...

   www.un4seen.com/stuff/xmplay.exe

If playback is paused, pressing the apply button in output settings and devices settings will resume playback.

The update above shouldn't resume playback in that case, but it will switch to a stopped state rather than remaining paused (as the output resources are released). But stopped and paused are basically the same thing, ie. pressing the play button will resume things

[bamf]

...

There are some differences in the track info, here are the screenshots of what's going on:
...

That looks like the playlist wasn't processed in the "fig a" case, ie. the playlist file itself (rather than its contents) was added to XMPlay's list. Do you know how the URL was passed to XMPlay in that instance, eg. was it via the command-line or DDE or OLE? What happens if you drag'n'drop the URL (eg. the links you posted earlier) into XMPlay?

if a link for the m3u/pls is created via windows explorer's .url file and drag'n'dropped onto XMPlay via OLE it opens/streams okay

how the URL was passed to XMPlay in that instance (of the application):  streamWriter is an open-source application. it uses drop-down boxes to select launch mode in object pascal forms.  its using a simple system call with the m3u/pls appended onto the default .m3u file handler's location (and then shelled)

It looks like XMPlay is lacking some sort of recursive processing when opening playlist/URL files

I can report that MPC-HC opens the streams okay from this application but not before a small anomaly where it looks like it opens/parses the m3u/pls with errors and then finds the IP:port of the server and proceeds on.  the same thing happens when it extract the .asf from some .asx files recursively to find the IP:port of the server.

[Ian @ un4seen]

I'll send you a debug version to confirm what XMPlay is receiving and how.

[tails_]

Problems with winamp plugins here: then you middle-click or select "Plug-in file info" in playlist window that does either nothing or breaks playback (some plugins just jump to next track some stop producing sound)

[Ian @ un4seen]

Strange. Which plugin(s) are you seeing that happen with? If you're unsure which is causing the problem, please try removing them one by one until you find the culprit.

[tails_]

Found culprit! That happens then current file is archived. Also while checking each plug in i noticed next problem: if you have 2 plugins which can playback same format (nezplug & notsofatso in my case) and priority given to second one, plugin file info option from playlist window still shows info given by first plugin.

[Ian @ un4seen]

Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

Let me know if either problem persists.

[tails_]

Works fine for me, thanks

Suggestion on unpacking plugins: could they be told somehow which files to extract and which not to?
Basic usage: you have CD image in FLAC with CUE sheet. Then you throw archive at XMPlay you get just FLAC file without CUE sheet so skipping tracks becomes somewhat problematic

UPD: Archived NSF is played with first plug-in and format priorities change nothing here
P.S. Playing NSF file archived is pretty weird idea, but just to check

[saga]

I think XMPlay disables the IT filter when a filter envelope reaches full cutoff again and resonance is disabled. In that case, returning full cutoff shouldn't change anything while the envelope is playing. Notice the subtle difference in the first pattern of the example file, directly after the filter envelope returns to full cutoff.