Author Topic: Bug in stream or XMPlay? (Read 23891 times)

quark · « **on:** 29 Aug '03 - 11:52 »

I just wonder why this stream makes XMPlay crash:

http://nectarine.turso.net:8000/necta.mp3

It's an experimantal Nectarine[1] 24K stream -- doesn't XMPlay support 24Kbits streams, or is the problem something else?

____
[1] http://www.scenemusic.net/

Torkell · « **Reply #1 on:** 29 Aug '03 - 13:43 »

Is it corrupt? XMPlay usually crashes when fed a corrupt file.

quark · « **Reply #2 on:** 29 Aug '03 - 13:51 »

XMPlay shouldn't crash because of corrupt streams, and I have no idea if the stream is corrupt or not. It might be, but XMPlay doesn't tell me that, it just commits suicide.

guest · « **Reply #3 on:** 29 Aug '03 - 14:01 »

Winamp 2 plays this stream...

Ian @ un4seen · « **Reply #4 on:** 29 Aug '03 - 16:03 »

Quote

Is it corrupt? XMPlay usually crashes when fed a corrupt file.

I wouldn't say that was particularly true... some corrupt files may cause XMPlay to crash, but the vast majority shouldn't do.

Anyway, in this case, the problem is that XMPlay doesn't like the position that the initial meta info comes at in the stream... I've sorted it for the next update.

Zarggg · « **Reply #5 on:** 29 Aug '03 - 22:51 »

Nectarine worked fine in 2.6 and 2.7, for sure. I don't know why it's crashing now. I'll have to test.

Ralesk · « **Reply #6 on:** 30 Aug '03 - 12:26 »

I use http://nectarine.ipsyn.net:8002/

quark · « **Reply #7 on:** 1 Sep '03 - 07:01 »

The Nectarine stream I posted is an experimental 24 Kbits stream, and not one of the ordinary 16 Kbits streams that have been around "forever". E.g., the ordinary streams work perfectly, but this new experimental one, doesn't.

Torkell · « **Reply #8 on:** 1 Sep '03 - 10:08 »

Quote

I wouldn't say that was particularly true... some corrupt files may cause XMPlay to crash, but the vast majority shouldn't do.

My experience is that corrupt modules generally cause XMPlay to crash. Did you ever look at the file that I uploaded to the usual place (Moors of Ireland, I believe it was)? That one is missing a few bytes as the result of a bad download.

Ralesk · « **Reply #9 on:** 1 Sep '03 - 22:42 »

Quote

The Nectarine stream I posted is an experimental 24 Kbits stream, and not one of the ordinary 16 Kbits streams that have been around "forever". E.g., the ordinary streams work perfectly, but this new experimental one, doesn't.

You do mean bits, and not kbits, yes?
Because ipsyn:Nectarine:8002 is 44.1KHz, 16bit, 2ch, 128kbit/s, MPEG1L3.
I don't think 24bit resolution would do much extra good for the modules that were made with 8 or 16 bit samples anyway.

Zarggg · « **Reply #10 on:** 2 Sep '03 - 06:49 »

Off-topic, but I can't get any of the Nectarine relays to work. When I try to add them by URI or .PLS, XMPlay just puts that red line through them or does nothing.

quark · « **Reply #11 on:** 2 Sep '03 - 18:21 »

Quote

You do mean bits, and not kbits, yes?

Of course. I just got a bit confused as the Nectarine webpage states:

Quote

Due to popular request, new experimental relays are now up at http://nectarine.turso.net:8000/necta.mp3 and http://nectarine.turso.net:8000/necta.ogg. This is a temporary solution until I can set these streams up at nectarine.oulu.fi. Streams might have some downtime sometimes as they are located on my home computer. Feedback and questions about these streams to necta@turso.net

guest · « **Reply #12 on:** 2 Sep '03 - 20:06 »

This is 24 kilo bits per second mono stream for people with e.g. modems.

Zarggg · « **Reply #13 on:** 3 Sep '03 - 01:18 »

Well, trying today to access http://nectarine.ipsyn.net:8006/ yeilds the following crash:

Code: [Select]

XMPLAY caused an invalid page fault in
module KERNEL32.DLL at 0177:bff9d7bd.
Registers:
EAX=0eb8fcd4 CS=0177 EIP=bff9d7bd EFLGS=00010246
EBX=0eb8ffbc SS=017f ESP=0eb9a64b EBP=0eb8fd04
ECX=d210cbc0 DS=017f ESI=8175ed28 FS=3cf7
EDX=c00300f0 ES=017f EDI=8174afd4 GS=0000
Bytes at CS:EIP:
50 68 78 a0 fc bf 68 02 00 00 80 68 11 00 01 00 
Stack dump:

Will try one of the experimentals.

Just tried. Same Crash.

Ian @ un4seen · « **Reply #14 on:** 3 Sep '03 - 12:32 »

All these streams are working with the latest "in development" version... 2.8.3 will be released shortly (once I've looked into the mysterious "GUI redrawing issue").

Zarggg · « **Reply #15 on:** 3 Sep '03 - 19:30 »

Until this is resolved, I'm forced to go back to using Wincramp. I've forgotten how ugly that GUI is. :laugh:

Jace · « **Reply #16 on:** 4 Sep '03 - 01:08 »

I got one case of 'the mysterious GUI redrawing issue' yesterday.. XMPlay was just over a clear desktop, I right-clicked the desktop, dropping the menu over xmp, and when it closed, I still could see the list on the background area (not sliders, buttons on anything) of xmp where it touched.

quark · « **Reply #17 on:** 4 Sep '03 - 06:38 »

Isn't it possible to have XMPlay use a 100% straight-forward Windows GUI when not skinned, and rather redraw the application into what it is now only when a skin is chosen?

I don't know which programming language XMPlay is written in, but if it's Delphi or C++, a normal GUI would behave the way Windows decides (e.g. without (many) bugs), and not the way XMPlay decides.

Just to get it straight: I'm not proposing to ditch the skinning-ability; I know people love this, but I just thought a non-skinned (default-looking) XMPlay could be without a skin and render a 100% ordinary Windows GUI.

Zarggg · « **Reply #18 on:** 4 Sep '03 - 14:20 »

As to the GUI bug, I've occasionally had the Vis window repaimt all over my screen. I never mentioned it because I thought I was the only one who had that problem.

Brightguy · « **Reply #19 on:** 4 Sep '03 - 22:35 »

I've had the vis. paint all over the screen before too... I'd click on "Add files" button and a shot of the vis. would suddenly appear there in the window. Hasn't happened in a while though.

Author Topic: Bug in stream or XMPlay? (Read 23891 times)

guest

guest