Topic: Radio stations not working in MC16 (Read 4798 times)

DiiPii · « **on:** July 30, 2011, 04:16:24 pm »

My radio stations that were working in MC15 (and still are) don't work in MC 16. error message says "MC encountered errors while trying to play files. Please make sure that the path in your media library points to the right location. Error details: Windows Media Error Unknown error(0xc00d0006)"

Here's an example of one of the radio stations. In MC 15, "file/open URL" plays this station: mms://69.59.140.90/zfzz2

any ideas? thanks

rick.ca · « **Reply #1 on:** July 30, 2011, 07:05:05 pm »

I suspect they haven't been working for quite some time. I don't use mine much, so I didn't notice a problem until earlier this week. Not being able to remember exactly when they did work, I decided to work back through previous builds until they worked again. I finally found one from sometime in May. Not seeing anything in the change logs, I started reinstalling later builds to find where they stopped working. Much to my surprise, they kept working right up to the current build. I then had to restore from backup, since I had used builds prior to a change in the Theatre View configuration. My Internet Radio streams continued to work for a short time, then spontaneously stopped working—just as when I had started.

So I haven't reported the matter until now because I'm not sure what to make of it. I intended to describe the behaviour in detail and provide logs (the program seems to get "stuck" doing something), but I haven't yet had time. So for now, I too can only ask...

any ideas?

And now that I know it's not just me, I'm curious—are they working for anyone?

marko · « **Reply #2 on:** July 30, 2011, 08:57:19 pm »

The link posted by DiiPii plays fine for me via "File > Open URL"...

* marko is listeng to: 'Today's Best Music, Z99 - Grand Cayman'

As do my saved stations...

* marko is listeng to: 'Real Radio Scotland' by 'Real Radio Scotland' from the album 'Real Radio Scotland' [Duration: 0:17 | kbps aac () | rated 4/5 | played 183 times ~ last played 31.1 days ago (29/06/11) Link

* marko is listeng to: 'BBC Radio 2' by 'BBC Radio 2' from the album 'BBC Radio 2' [Duration: 0:06 | kbps asf () | rated 4/5 | played 209 times ~ last played 1:57 ago (31/07/11) Link

* marko is listeng to: 'BBC Radio 3' by 'BBC Radio 3' from the album 'BBC Radio 3' [Duration: 0:07 | kbps asf () | rated ? stars/5 | played 40 times ~ last played 160.6 days ago (20/02/11) Link

What I do notice is that it takes a good 30 - 45 seconds for the stream to actually stop playing after pressing the stop button, and MC really does not like skipping from one stream to another without stopping first.

marko · « **Reply #3 on:** July 30, 2011, 09:20:20 pm »

However, on my HTPC, which is a library server client, none of the "MMS:" streams will play. MC reports "Something went wrong with playback. Windows Media Error: Unknown Error (0xc00d2ee2)"

Restarting MC there does not help, but closing MC, then restarting the server, then starting MC on the HTPC again does fix the MMS issues there. Not sure how long it will stay fixed however.

Something flakey going on, that's for sure. W7 x64, latest MC build.

rick.ca · « **Reply #4 on:** July 31, 2011, 01:36:46 pm »

I still haven't had time to test this further and capture logs, but some fairly consistent observations are...

• most stream take a very long time to get started (maybe 30 - 60 seconds, if ever), during which time the program is unresponsive.

• if a stream does get started, it plays with muffled chirps occurring a frequency of about one/second.

• in foobar2000, the streams start immediately and play properly.

Quote from: marko on July 30, 2011, 09:20:20 pm

Something flakey going on, that's for sure. W7 x64, latest MC build.

If we're going to be technical about it...ditto.

DiiPii · « **Reply #5 on:** August 02, 2011, 08:39:20 am »

Thanks for the posts. Spent ages trying to figure this out.....turns out it was the firewall. I hadn't added an exception for MC16. doh!

JimH · « **Reply #6 on:** August 11, 2011, 01:56:56 pm »

The above URL works for me in File/Open URL:
mms://69.59.140.90/zfzz2

As DiiPii said, the firewall needed to be opened.

rick.ca · « **Reply #7 on:** August 11, 2011, 02:18:49 pm »

Quote

As DiiPii said, the firewall needed to be opened.

I could find no indication my security software was interfering at all. The behaviour is the same with it shut down (although I'm uncomfortable testing that for any length of time). I'd also be surprised if that were the cause of marko's problems. Or if it were, that he would not say so.

JimH · « **Reply #8 on:** August 11, 2011, 02:56:15 pm »

Can you play it?

Quote from: JimH on August 11, 2011, 01:56:56 pm

The above URL works for me in File/Open URL:
mms://69.59.140.90/zfzz2

As DiiPii said, the firewall needed to be opened.

rick.ca · « **Reply #9 on:** August 11, 2011, 03:14:51 pm »

Quote

Can you play it?

All I can say about it at this point is in my post above.

JimH · « **Reply #10 on:** August 11, 2011, 03:27:51 pm »

I'll take that as a "no".

rick.ca · « **Reply #11 on:** August 11, 2011, 07:16:53 pm »

That stream works now, but I have no idea what that says about the issue. It did not work when I originally posted here. And none of streams I use work properly. They're mp3, aac and ogg—not mms.

I don't much care. I collected an catalogued some streams because it could be done. But others are having problems too. Does no one have anything to say about what I've already reported? I have no idea whether this is an obscure problem I happen to have, or I'm just one of very few users who attempt to play a variety of different streams.

Quote from: rick.ca on July 31, 2011, 01:36:46 pm

I still haven't had time to test this further and capture logs, but some fairly consistent observations are...
• most stream take a very long time to get started (maybe 30 - 60 seconds, if ever), during which time the program is unresponsive.
• if a stream does get started, it plays with muffled chirps occurring a frequency of about one/second.
• in foobar2000, the streams start immediately and play properly.

I was hoping for at least some tidbit that might focus my testing before I waste any more time on the issue.

JimH · « **Reply #12 on:** August 11, 2011, 07:36:37 pm »

It may be the firewall.

rick.ca · « **Reply #13 on:** August 11, 2011, 10:21:28 pm »

Quote

It may be the firewall.

Not when the firewall has been disabled.

Attached are some logs. Every stream takes a very long time to start (most over 60 seconds). One caused a hang, but I suspect any of them would had I attempted to do anything before they started. Most play with periodic muffled chirps of varying types. All start instantly and play properly in foobar2000.

rick.ca · « **Reply #14 on:** August 15, 2011, 01:39:12 pm »

JimH · « **Reply #15 on:** August 15, 2011, 01:44:57 pm »

Can you give me a couple of examples that won't work?

rick.ca · « **Reply #16 on:** August 15, 2011, 02:13:44 pm »

Each of the six logs I provided clearly show the stream involved.

MrC · « **Reply #17 on:** August 15, 2011, 02:25:22 pm »

Here were my results. They all sounded fine.

AAC slow start
  http://voxsc1.somafm.com:8070
no issues here

AAC slow start + distortion
  http://95.154.211.15:11278
no issues here.

MP3 slow start + distortion
  http://scfire-mtc-aa04.stream.aol.com:80/stream/1022
no issues here.

MP3 slow start + distortion 2
  http://85.114.133.88:8253
no issues here.

MP3 slow start + distortion 3
  http://streamer-mtc-aa02.somafm.com:80/stream/1018
no issues here.

OGG hang
  http://stream-sd.radioparadise.com:9000/rp_192.ogg
no issues here.

MrC · « **Reply #18 on:** August 15, 2011, 02:37:15 pm »

Quote from: rick.ca on August 11, 2011, 10:21:28 pm

Not when the firewall has been disabled.

Every stream takes a very long time to start (most over 60 seconds). One caused a hang, but I suspect any of them would had I attempted to do anything before they started. Most play with periodic muffled chirps of varying types. All start instantly and play properly in foobar2000.

Maybe this is just a terminology issue here, and this is just for the record, but firewalls will allow/deny the connection, they aren't involved once the ports are open and data is passing through the socket.

Now a real-time virus scanner or content inspection engine will inject itself to determine possible threats, based up heuristics and patterns. These typically buffer content. Norton is, sorry to say, notoriously meddlesome. (Users often see this with email, where the Norton email proxy holds a message until it is satisfied. But some messages can cause Norton to never be satisfied, so it hangs onto them and the user doesn't see them. I've verified this through mail server transaction and IMAP logs, and client mail logs. The server indicates the message was delivered to an inbox, it shows in the inbox, but the client doesn't pick it up. Culprit - Norton. Disable its email scanning proxy, and the message comes through.)

rick.ca · « **Reply #19 on:** August 15, 2011, 02:53:20 pm »

Quote

Here were my results. They all sounded fine.

Thanks for checking. Do my logs suggest anything to you about what might be going wrong (other than the possibility of the real-time virus scanner interfering)? Could you provide the corresponding part of you own log for one of them so we can compare? Maybe it will be apparent it's doing "this" when it should be doing "that." $:-\$

Quote

Now a real-time virus scanner or content inspection engine will inject itself to determine possible threats...

I use McAfee, which I have reason to mistrust it as much as Norton. I'll try disabling the real-time scanning as well...

JimH · « **Reply #20 on:** August 15, 2011, 03:29:57 pm »

I tried the first three in MrC's post. They all play without problems. I used File/Open URL.

MrC · « **Reply #21 on:** August 15, 2011, 03:40:42 pm »

Quote from: rick.ca on August 15, 2011, 02:53:20 pm

Thanks for checking. Do my logs suggest anything to you about what might be going wrong (other than the possibility of the real-time virus scanner interfering)? Could you provide the corresponding part of you own log for one of them so we can compare? Maybe it will be apparent it's doing "this" when it should be doing "that." $:-\$

I can send some logs if necessary. This log from:

AAC slow start.txt: http://voxsc1.somafm.com:8070

seems OK, but I'm no expert at MC log reading.

The stream is >120K bps, so that's at least 15,360 bytes / second needed to allow continuous playback.

Looks like playback starts about 9 seconds after logging:

0009001: 4836: Playback: CPlayerZone::Play: Processing play for 'http://voxsc1.somafm.com:8070'

In just under the 1st second, MC has read 32768 + 32768 + 65536 + 131072 = 262,144 bytes, so that's good enough for about 17 seconds (minus overhead - I don't know what percentage to estimate here).

0009984: 4836: Playback: JRURLStream::Read: Bytes to read 32768, bytes read 32768, align 1
0009984: 4836: Playback: JRURLStream::Read: Finish (0 ms)
0009999: 4836: Playback: JRURLStream::SetPointer: Start
0009999: 4836: Playback: JRURLStream::SetPointer: Pos 32768, ret 32768
0009999: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0009999: 4836: Playback: JRURLStream::Read: Start
0010062: 4836: Playback: JRURLStream::Read: Bytes to read 32768, bytes read 32768, align 1
0010062: 4836: Playback: JRURLStream::Read: Finish (63 ms)
0010077: 4836: Playback: JRURLStream::SetPointer: Start
0010077: 4836: Playback: JRURLStream::SetPointer: Pos 65536, ret 65536
0010077: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0010077: 4836: Playback: JRURLStream::Read: Start
0010265: 4836: Playback: JRURLStream::Read: Bytes to read 65536, bytes read 65536, align 1
0010265: 4836: Playback: JRURLStream::Read: Finish (188 ms)
0010280: 4836: Playback: JRURLStream::SetPointer: Start
0010280: 4836: Playback: JRURLStream::SetPointer: Pos 131072, ret 131072
0010280: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0010280: 4836: Playback: JRURLStream::Read: Start
0010561: 4836: Playback: JRURLStream::Read: Bytes to read 131072, bytes read 131072, align 1
0010561: 4836: Playback: JRURLStream::Read: Finish (281 ms)
0010592: 4836: Playback: JRURLStream::SetPointer: Start
0010592: 4836: Playback: JRURLStream::SetPointer: Pos 262144, ret 262144
0010592: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0010592: 4836: Playback: JRURLStream::Read: Start

Now, 16 seconds later, MC reads another 786,432 bytes (262144 + 524288) , about 51 seconds or so worth:

0026224: 4836: Playback: JRURLStream::Read: Bytes to read 262144, bytes read 262144, align 1
0026224: 4836: Playback: JRURLStream::Read: Finish (15632 ms)
0026270: 4836: Playback: JRURLStream::SetPointer: Start
0026270: 4836: Playback: JRURLStream::SetPointer: Pos 524288, ret 524288
0026270: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0026270: 4836: Playback: JRURLStream::Read: Start
0058968: 4836: Playback: JRURLStream::Read: Bytes to read 524288, bytes read 524288, align 1
0058968: 4836: Playback: JRURLStream::Read: Finish (32698 ms)

And at 61.168 seconds, it starts reading again, all fast enough to enjoy stutter-free playback:

0061168: 4836: Playback: JRURLStream::Read: Bytes to read 32768, bytes read 32768, align 1
0061168: 4836: Playback: JRURLStream::Read: Finish (2091 ms)
0061168: 4836: Playback: JRURLStream::SetPointer: Start
0061168: 4836: Playback: JRURLStream::SetPointer: Pos 0, ret 0
0061168: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0061168: 4836: Playback: JRURLStream::Read: Start
0061168: 4836: Playback: JRURLStream::Read: Bytes to read 32768, bytes read 32768, align 1
0061168: 4836: Playback: JRURLStream::Read: Finish (0 ms)
0061168: 4836: Playback: JRURLStream::SetPointer: Start
0061168: 4836: Playback: JRURLStream::SetPointer: Pos 32768, ret 32768
0061168: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0061168: 4836: Playback: JRURLStream::Read: Start
0061168: 4836: Playback: JRURLStream::Read: Bytes to read 32768, bytes read 32768, align 1
0061168: 4836: Playback: JRURLStream::Read: Finish (0 ms)

So it seems that for about the first minute roughly, MC is reading enough data, and fast enough to maintain playback.

rick.ca · « **Reply #22 on:** August 15, 2011, 04:10:16 pm »

I don't understand much of what's in the logs either, but this 33 second gap (in the same log) looks very odd—considering playback has still not begun... $:-\$

Code: [Select]

0026270: 4836: Playback: JRURLStream::SetPointer: Pos 524288, ret 524288
0026270: 4836: Playback: JRURLStream::SetPointer: Finish (0 ms)
0026270: 4836: Playback: JRURLStream::Read: Start
0058968: 4836: Playback: JRURLStream::Read: Bytes to read 524288, bytes read 524288, align 1
0058968: 4836: Playback: JRURLStream::Read: Finish (32698 ms)

And then this...

Code: [Select]

0061183: 4836: Playback: 0x12e4 DumpGraph: Start
0061183: 4836: Playback: 0x12e4 DumpGraph: Log_DumpGraph [134c3a8]
0061183: 4836: Playback: 0x12e4 DumpGraph:     Filter [62aea24]  'JRiver Audio Renderer'
0061183: 4836: Playback: 0x12e4 DumpGraph:         CLSID: {EC1F74A8-7E55-4814-9F9F-D417489075CA}
0061183: 4836: Playback: 0x12e4 DumpGraph:         Host: 
0061183: 4836: Playback: 0x12e4 DumpGraph:           Pin [62aed94]  'In' [Input]  Connected to pin [31b31bc]
0061183: 4836: Playback: 0x12e4 DumpGraph:     Filter [31b29ec]  'LAV Audio Decoder (auto-configured)'
0061183: 4836: Playback: 0x12e4 DumpGraph:         CLSID: {E8E73B6B-4CB3-44A4-BE99-4F7BCB96E491}
0061183: 4836: Playback: 0x12e4 DumpGraph:         Host: C:\Users\Rick\AppData\Roaming\J River\Media Center 16\Plugins\lav\LAVAudio.ax
0061183: 4836: Playback: 0x12e4 DumpGraph:           Pin [31b30a4]  'Input' [Input]  Connected to pin [d058904]
0061183: 4836: Playback: 0x12e4 DumpGraph:           Pin [31b31bc]  'Output' [Output]  Connected to pin [62aed94]

...suggests to me the manner in which streams are handled must have changed with RO. LAVAudio wasn't in the picture until then, was it?

MrC · « **Reply #23 on:** August 15, 2011, 04:36:17 pm »

The gap seems OK, because there's enough data to fill the pipe.

BUT, you've hit on the difference. I have no LAV or anything else in my logs. See attached.

Side by side, we see very different paths.

And mine is trying to play

Filetype: aac; Type: 1;

Yours

Filetype: aac; Type: 2;

rick.ca · « **Reply #24 on:** August 15, 2011, 05:30:57 pm »

Quote

The gap seems OK, because there's enough data to fill the pipe.

It would be "okay" IF playback had started.

Quote

BUT, you've hit on the difference. I have no LAV or anything else in my logs.

That's interesting! And it's doing the same thing in all cases—regardless of file type. So it seems it's trying to handle them as video streams. No wonder it's having difficulty.

~~Now hopefully a developer can comment on why that is so, and what I might do about it.~~

I think I've found the cause of my problem. Many/most of my audio file types had their playback method set to "JRiver Audio engine." I don't know why I would have done that, other than for AAC—for which I had been using the Orban filter. Maybe I accidentally set the others when I was setting that. Anyway, all seems well now that I've set them to "Automatic."

Thanks very much for your help.

MrC · « **Reply #25 on:** August 15, 2011, 06:22:16 pm »

Glad you found it!

INTERACT FORUM

Author Topic: Radio stations not working in MC16 (Read 4798 times)