UBURadio stops after some 15-60 seconds

[pz1]

Great plugin. This is what i have been wating for a long time. Unfortunately in time shifted mode after some time (15-60 seconds) the stream stops, though the screen continues to tell me that it is playing. Also VLC continues to run. I observe this both at the PC console as via MVP.

In preview mode on the PC console it plays uninterrupted. Any clue of what might be the problem?

I could not find any clues in the standard logfiles. Attached is the VLC log. (see signature for my configuration)

[ubu]

Great plugin. This is what i have been wating for a long time. Unfortunately in time shifted mode after some time (15-60 seconds) the stream stops, though the screen continues to tell me that it is playing. Also VLC continues to run. I observe this both at the PC console as via MVP.

In preview mode on the PC console it plays uninterrupted. Any clue of what might be the problem?

I could not find any clues in the standard logfiles. Attached is the VLC log. (see signature for my configuration)

The log confirms what you already noticed: VLC continued to run because it was successfully transcoding the stream. If the GB-PVR player stops playing after a few seconds, it usually means that it ran out of data to read in the transcoded file. So you should probably increase the value of the WaitTime field in the UbuRadio config panel (or just manually change it in the UbuRadio section of the gbpvr Config.xml file).

It's tricky getting this value just right since it depends on the speed of the stream itself (including the response time of the stream server), your network bandwidth (which can vary in "actual" terms throughout the day) and the horsepower of your CPU. For what it's worth, on my GB-PVR systems (2.xGhz P4s and cable broadband) I'm using a wait time of 10,000 for MVP use and 5,000 for regular GB-PVR use. This handles even the tardiest streams for me. People who don't have any "slow response" stations in their favourites list can probably get away with much lower numbers.

Since I designed UbuRadio to be very simple to use, you can only set a single WaitTime for all stations. The next release of UbuStream (which I hope to announce in beta form soon) will allow you to set several different options to do with wait times for each station individually. So then people can go crazy fine-tuning each station to its optimal delay.

If increasing the WaitTime value doesn't solve the problem, send me the gbpvr.exe.log (which will show us what the audio player was doing) and I'll take a look.

[pz1]

The log confirms what you already noticed: VLC continued to run because it was successfully transcoding the stream. If the GB-PVR player stops playing after a few seconds, it usually means that it ran out of data to read in the transcoded file. So you should probably increase the value of the WaitTime field in the UbuRadio config panel (or just manually change it in the UbuRadio section of the gbpvr Config.xml file).

It's tricky getting this value just right since it depends on the speed of the stream itself (including the response time of the stream server), your network bandwidth (which can vary in "actual" terms throughout the day) and the horsepower of your CPU. For what it's worth, on my GB-PVR systems (2.xGhz P4s and cable broadband) I'm using a wait time of 10,000 for MVP use and 5,000 for regular GB-PVR use. This handles even the tardiest streams for me. People who don't have any "slow response" stations in their favourites list can probably get away with much lower numbers.

Since I designed UbuRadio to be very simple to use, you can only set a single WaitTime for all stations. The next release of UbuStream (which I hope to announce in beta form soon) will allow you to set several different options to do with wait times for each station individually. So then people can go crazy fine-tuning each station to its optimal delay.

If increasing the WaitTime value doesn't solve the problem, send me the gbpvr.exe.log (which will show us what the audio player was doing) and I'll take a look.

I had it on 10,000 as a matter of fact. So increased to 15,000, later back to 5,000. No effect. In order to prepare gbpvr.exe.log for my response to you I changed its settings to 'debug' , next I tried to repeat the problem. To my surprise it had gone, and dit not return after setting the logging level back to 'error'. I remain puzzled. Even the WILL stream (Urbana, Illinois, where I lived mid 70's) is not choppy any more.
PS: The link I got from the system for WILL appeared to be wrong, so I edited the correct one directly in the XML.

[ubu]

I had it on 10,000 as a matter of fact. So increased to 15,000, later back to 5,000. No effect. In order to prepare gbpvr.exe.log for my response to you I changed its settings to 'debug' , next I tried to repeat the problem. To my surprise it had gone, and dit not return after setting the logging level back to 'error'. I remain puzzled. Even the WILL stream (Urbana, Illinois, where I lived mid 70's) is not choppy any more.

Sunspots? Sometimes it's hard to find a logical explanation. For instance, rebooting often solves many problems.

PS: The link I got from the system for WILL appeared to be wrong, so I edited the correct one directly in the XML.

The source I'm using for the stations is fairly up to date but, as I'm sure you're aware, station URLs do change from time to time so not all the links are guaranteed to be valid. However, the web site URLs are usually correct so you can click Web Site and see if there's a new URL for the strteam (you have to use the mouse if you want to navigate in the web viewer - providing a full blown web browser for GB-PVR is a bit beyond my scope).

[pz1]

Sunspots? Sometimes it's hard to find a logical explanation. For instance, rebooting often solves many problems.

I did a reinstall. Same bug appeared. The reboot cured it.

However I now bumped into the next problem. After a 2 hour period of playing, the music suddenly stops. On screen there is a debug message to Microsoft message telling me that VLC stopped suddenly. None of the GBPVR logs has written about this event (obviously I think). At the moment the music stopped the VLC log (attached) has changed.
I observed this behaviour yesterday as well. Did measure palying time then.
Due you have a clkue what might be happening?

PS: I did remove Ubustream in the meantime. I only got it working properly with NASA TV, which I found extremely boring. I originally installed ubustream because I hoped to get to internet radio ultimately.

[ubu]

IHowever I now bumped into the next problem. After a 2 hour period of playing, the music suddenly stops. On screen there is a debug message to Microsoft message telling me that VLC stopped suddenly. None of the GBPVR logs has written about this event (obviously I think). At the moment the music stopped the VLC log (attached) has changed.
I observed this behaviour yesterday as well. Did measure palying time then.
Due you have a clkue what might be happening?

Short answer: I can't tell you for sure why that's happening.

Long answer: there's a lot of reasons why a stream might stop playing, some related to VLC, some related to the UbuRecordingService.

VLC

The VLC log doesn't tell us much but that's not surprising since the MS debug message you got indicates that VLC terminated abnormally so it probably didn't get a chance to write anything to the log when it died. VLC is a great piece of software but it is free and its developed by a bunch of volunteers, not by a major corporation (much like GB-PVR and its plugins). So sometimes introduction of new features comes at the cost of stability in some areas. I experience that certain situations will cause VLC to just fall over. Transcoding network streams is complicated and so VLC may show its fragility when it encounters some unexpected condition.

UbuRecordingService

I developed the UbuRecordingService primarily to stop orphan VLC transcoding processes from continuing to record to your hard disk until it fills up. It relies on the parent app sending a message (every 5 seconds or so) telling it to keep recording. If something happens to interfere with this (like an intense CPU spike) it could mess up the timing so it misses a message and, therefore kills the VLC recording process. I've seen this happen occasionally when Comskip is processing a TV recording, for instance.

Obviously, the UbuRecordingService will also shut down the VLC process if explicitly told to do so (pressing the Stop button or exiting from GB-PVR). UbuRadio will also tell it to stop if it detects the recording has been unsuccessful (empty file, invalid format, etc.).

Fail safe

There's one situation that's a bit of a kludge, though. If you are using an MVP and you get the wait time wrong such that VLC starts recording but GB-PVR tries to play it back too quickly and fails to start playing (you'll see the VLC process clocking but nothing playing on your MVP), I have no way of knowing that has happened. I hope the user will hit the Stop button, or try another station (which will kill the "orphan" VLC process) but, if they just walk away in disgust, the VLC process will continue recording forever.

I have asked sub to add a function to the GB-PVR API that would let me detect if the MVP is actually playing the file and he said he'd include it in a future release. However, in the meantime, to handle this eventuality, I have placed an arbitrary cap of 60 minutes for MVP playback. However this also means that, even for a stream that is playing successfully, it will just stop playing after 60 minutes. You just have to hit the play button and it will start again.

Bottom line

I've no idea which of the above situations is causing your stream to stop playing. If you're interested in trying to track it down you can look at the gbpvr.exe.log, which contains messages from the Ubu components, including requests to the recording service, and at your Windows event log, which contains messages from the UbuRecordingService (you should see "CONT", "OK" pairs for the "stay alive" transactions and requests for things like "START" and "STOP").

My own experience is also that web streams are inately unreliable. Sometimes they stutter, sometimes they just stop. Some streams seem more reliable than others. My favourite station quite often drops the stream for no apparent reason. I just hit Stop and then Play and I'm happily listening to it again.

PS: I did remove Ubustream in the meantime. I only got it working properly with NASA TV, which I found extremely boring. I originally installed ubustream because I hoped to get to internet radio ultimately.

The current release of UbuStream has pretty limited support for MVP users (pity you used NASA TV, which, I agree, is fairly tedious, as your test case - Research TV, which works well for MVPs, is a bit more interesting). In any case, the next release of UbuStream (quite soon) will provide much enhanced support for the MVP.

[pz1]

UBU, thanks for the extensive and usefull comment. I hope you did not take my comments as to negative. I highly appreciate the work you are doing on these plugins. I do understand the difficulties of streaming media over the internet. Actually I am amazed that this protocol does things it has not been designed for, so well. For the time being i will hit the play button once in a while.

I did install this one because you explicitly asked for an extended userbase to test the radio plugin. I happy to help out, and I will continue to give that feedback. In the context of what you have written, I do not expect you solve all of it. It might help you finding weak spots in the present implementation.
So some observations:
1) I do notice that the streams played in sub's standard Net Radio (shoutcast) are much more stable. These will run for hours.
2) In Uburadio I had one MP3 stream which played at least three hours time shifted on the PC console.
3) I got the impression that some streams play longer in preview mode than in timeshifted mode.

As said impressions not solid scientific proof.

[ubu]

UBU, thanks for the extensive and usefull comment. I hope you did not take my comments as to negative. I highly appreciate the work you are doing on these plugins. I do understand the difficulties of streaming media over the internet. Actually I am amazed that this protocol does things it has not been designed for, so well. For the time being i will hit the play button once in a while.

Thanks for the kind words. It's tough, but somebody had to do it.

I did install this one because you explicitly asked for an extended userbase to test the radio plugin.

I did? I must have been crazy.

I happy to help out, and I will continue to give that feedback. In the context of what you have written, I do not expect you solve all of it. It might help you finding weak spots in the present implementation.

I certainly appreciate it.

1) I do notice that the streams played in sub's standard Net Radio (shoutcast) are much more stable. These will run for hours.

That's because Shoutcast streams are already in MP3 format so require little or no transcoding to play with the GB-PVR audio player. Also, Net Radio was written by sub. As the author of GB-PVR, it's entirely possible he knows things that I don't.

2) In Uburadio I had one MP3 stream which played at least three hours time shifted on the PC console.

Same reason. VLC has to do much less work to "transcode" an MP3 stream to an MP3 file. Streams in WMP, OggVorbis, etc. formats make it do more work, requiring more resources and, therefore, inherently expose Timeshift playback to timing issues. And, btw, as I mentioned in my earlier post, the arbitrary 60 minute limit only applies to MVP playback so stations should, in theory, keep playing on your PC as long as you like.

3) I got the impression that some streams play longer in preview mode than in timeshifted mode.

Well they would, if you think about it. The internal players (Preview mode) are just embedded versions of the regular external players so, if a stream hiccups (as they quite often do - either caused by the stream server itself, network variations, or by you stealing bandwidth by downloading a huge email attachement to your laptop) the player will usually recover and keep going. If the same thing happens in timeshift mode, VLC will stop writing to the MP3 file and, if the GB-PVR player catchs up with it, it thinks it's hit the end of the file and stops playing.

I can't think of any good way round this. I've provided a configurable Wait Time so you can at least give VLC a chance to get a good start ahead of the GB-PVR player. In the next version of UbuStream this will be configurable for each individual station so you can fine tune "problem" stations (but not in UbuRadio - I want to keep that very simple).

As you pointed out, trying to treat network streams as if they were conventional broadcast stations presents certain "difficulties". It's really like attempting to "square the circle". I'm constantly amazed that it's possible at all, as I sit on my couch listening to radio stations from all over the world and watching a variety of streaming TV news, movies, etc. (especially since I live behind a mountain and can't receive terrestrially broadcast radio or TV at all). Unfortunately, anyone who expects it to behave as reliably and predictably as their set top box signal is going to be somewhat out of luck.

Thanks again for your comments. Let me know if you find any bugs (at least ones I can fix ). I'll be putting out a bug fix release of UbuRadio some time this week.

[ubu]

UBU, thanks for the extensive and usefull comment. I hope you did not take my comments as to negative. I highly appreciate the work you are doing on these plugins. I do understand the difficulties of streaming media over the internet. Actually I am amazed that this protocol does things it has not been designed for, so well. For the time being i will hit the play button once in a while.

Thanks for the kind words. It's tough, but somebody had to do it.

I did install this one because you explicitly asked for an extended userbase to test the radio plugin.

I did? I must have been crazy.

I happy to help out, and I will continue to give that feedback. In the context of what you have written, I do not expect you solve all of it. It might help you finding weak spots in the present implementation.

I certainly appreciate it.

1) I do notice that the streams played in sub's standard Net Radio (shoutcast) are much more stable. These will run for hours.

That's because Shoutcast streams are already in MP3 format so require little or no transcoding to play with the GB-PVR audio player. Also, Net Radio was written by sub. As the author of GB-PVR, it's entirely possible he knows things that I don't.

2) In Uburadio I had one MP3 stream which played at least three hours time shifted on the PC console.

Same reason. VLC has to do much less work to "transcode" an MP3 stream to an MP3 file. Streams in WMP, OggVorbis, etc. formats make it do more work, requiring more resources and, therefore, inherently expose Timeshift playback to timing issues. And, btw, as I mentioned in my earlier post, the arbitrary 60 minute limit only applies to MVP playback so stations should, in theory, keep playing on your PC as long as you like.

3) I got the impression that some streams play longer in preview mode than in timeshifted mode.

Well they would, if you think about it. The internal players (Preview mode) are just embedded versions of the regular external players so, if a stream hiccups (as they quite often do - either caused by the stream server itself, network variations, or by you stealing bandwidth by downloading a huge email attachement to your laptop) the player will usually recover and keep going. If the same thing happens in timeshift mode, VLC will temporarily stop writing to the MP3 file and, if the GB-PVR player catchs up with it, it thinks it's hit the end of the file and stops playing.

I can't think of any good way round this. I've provided a configurable Wait Time so you can at least give VLC a chance to get a good start ahead of the GB-PVR player. In the next version of UbuStream this will be configurable for each individual station so you can fine tune "problem" stations (but not in UbuRadio - I want to keep that very simple). So - keep your remote handy at all times so you can hit Play again when it does happen.

As you pointed out, trying to treat network streams as if they were conventional broadcast stations presents certain "difficulties". It's really like attempting to "square the circle". I'm constantly amazed that it's possible at all, as I sit on my couch listening to radio stations from all over the world and watching a variety of streaming TV news, movies, etc. (especially since I live behind a mountain and can't receive terrestrially broadcast radio or TV at all). Unfortunately, anyone who expects it to behave as reliably and predictably as their set top box signal is going to be somewhat out of luck.

Thanks again for your comments. Let me know if you find any bugs (at least ones I can fix ). I'll be putting out a bug fix release of UbuRadio some time this week.

[pz1]

As the author of GB-PVR, it's entirely possible he knows things that I don't.

Let's send the marines to Wellington beach and squeeze it out of him