Problem playing Ubustream over MediaMVP

[gnutech]

I have followed jbyram2's guide on setting up Ubustream for use with the MediaMVP. It works great under channel mode on my computer, but when I try to stream it using channel mode over the MediaMVP it acts like it is trying to do it (black screen) then it returns to the channel listings (I'm using the TV Listings plugin).

I have also noticed that when I stop the Ubustream on my computer that a new instance of vlc is opened and then close, but the existing instance of vlc remains. I thought configuring VLC with settings->preferences advanced, check advanced options and select "allow only one running instance" and "allow only one running instance when started from a file" keep "use a plugins cache" checked. all others on that page unchecked. along with the "--one-instance vlc:quit" options in External Recorder were suppose to stop vlc.

Your assistance is greatly appreciated.

Respectfully,


Gary

[jbyram2]

I have followed jbyram2's guide on setting up Ubustream for use with the MediaMVP. It works great under channel mode on my computer, but when I try to stream it using channel mode over the MediaMVP it acts like it is trying to do it (black screen) then it returns to the channel listings (I'm using the TV Listings plugin).

Some channels do this for me also, especially if they are offline/insufficient bandwidth connections. Even good connections take several seconds to get started. be sure the Wait times are adjusted as indicated in the guide.

I have also noticed that when I stop the Ubustream on my computer that a new instance of vlc is opened and then close, but the existing instance of vlc remains. I thought configuring VLC with settings->preferences advanced, check advanced options and select "allow only one running instance" and "allow only one running instance when started from a file" keep "use a plugins cache" checked. all others on that page unchecked. along with the "--one-instance vlc:quit" options in External Recorder were suppose to stop vlc.

Your assistance is greatly appreciated.

Respectfully,
Gary

Not sure what is happening there, but it sounds like the "one instance" setting isn't working somehow. That was the behavior I saw before I turned on one instance.

Unfortunately I broke my Ubustream setup updating to V2.0, and haven't quite fixed it yet. If I get the same... well, I'll tell how I fixed it. *crosses fingers for success*

[ubu]

I have also noticed that when I stop the Ubustream on my computer that a new instance of vlc is opened and then close, but the existing instance of vlc remains. I thought configuring VLC with settings->preferences advanced, check advanced options and select "allow only one running instance" and "allow only one running instance when started from a file" keep "use a plugins cache" checked. all others on that page unchecked. along with the "--one-instance vlc:quit" options in External Recorder were suppose to stop vlc.

What version of VLC are you using? Version 0.8.6 was just released so you might try that and see if the "single instance" setting works any better for you.

For UbuStream v2.0, I added code to explicitly kill the player process when you select a different station in list mode (or select the Stop button) - the intent being to supress spurious player instances even if you don't have the "single instance" option set (and also work for other players that don't have an equivalent option). I couldn't do the same thing for channel mode since, once UbuStreamCmd.exe has executed, control is passed to ExternalRecorder. I guess I could write a little app to kill VLC instances that you could use in the Stop Recording Executable field of the ExternalRecorder config, but it would be better if we can get VLC to work "as advertised" and do this for us.

[gnutech]

I was running VideoLAN 0.8.5, so I updated to VideoLAN 0.8.6 as recommended. This did not remedy either the one-instance vlc:quit or streaming over MediaMVP issues.

I played around with External Recorder's "output file" and "before starting 'Now Recording'" wait times, but nothing seemed to help. I ended up putting them back to their originial, respective times of 10,000 ms and 100 ms.

As for the vlc:quit issue, I decided to change the "Stop Recording" and "Stop Preview" Executable and Parameters to the following work-around:

Stop Recording Executable: C:\WINDOWS\system32\cmd.exe
Stop Recording Parameters: /c taskkill /IM vlc.exe
Stop Preview Executable: C:\WINDOWS\system32\cmd.exe
Stop Preview Parameters: /c taskkill /IM vlc.exe

This killed the vlc.exe processes without issue. Then External Recorder seemed to clean up the transcoded destination file very nicely.

Let me know if you get Ubustream 2.0 working with VideoLAN 0.8.6.

Respectfully,


Gary

[ubu]

I was running VideoLAN 0.8.5, so I updated to VideoLAN 0.8.6 as recommended. This did not remedy either the one-instance vlc:quit or streaming over MediaMVP issues.

Not sure I'm "recommending" 0.8.6 yet. It just seems that 0.8.5 introduced some problems which 0.8.6 is supposed to fix (in addition to improved support for various codecs) . One thing that confuses me about your problem is that a fair number of MVP users have reported successfully using the channel mode feature with UbuStream v1.6. One possibility is that they may be using VLC 0.4.0 (or 0.4a) which was a very stable release. I haven't changed the code relating to channel mode for UbuStream v2.0 so it should work the same.

I played around with External Recorder's "output file" and "before starting 'Now Recording'" wait times, but nothing seemed to help. I ended up putting them back to their originial, respective times of 10,000 ms and 100 ms.

Are you testing with just one url or with several different ones? I'm working on MVP support for UbuStream list mode and I'm using a similar technique to wait for the file to be created before playing it. I'm testing with the Research Channel (pretty stable, reliable stream) and I find that using 5000 ms and 100 ms gives fairly consistent results. Some streams have a tendency to connect, start streaming for a second or two, then stop and refill the buffer before continuing to play. I'm wondering if this confuses the gbpvr video player since the file would show up quickly but would not have enough content for the video player to play. I don't know what values you have tried for these fields but, if you tried upping the second one from 100 ms to some really big number - a minute maybe - it would test this theory.

I'm also not sure whether there are additional timing checks in the MVP dongle code that affect this (especially since you don't experience the problem when using timeshift mode on the PC). One problem I have is that I don't have an MVP (although I've asked Santa to bring me one ) so I have, up to now, had to assume that if I can get something working in GBPVR's timeshift mode it will work for MVP users.

This killed the vlc.exe processes without issue. Then External Recorder seemed to clean up the transcoded destination file very nicely.

Well that's a good workaround. External Recorder "should" kill the vlc process once it detects that you have exited from the gbpvr video player. Also, it doesn't delete the output file itself but seems to rely on gbpvr's timeshift mode logic to do the clean up. So I'm still confused why this wasn't working properly for you. Also, I can't reproduce the problem you're having with the "allow only one running instance" preference. For me (using both 0.8.5 and 0.8.6) it seems to work as expected both when running vlc from the desktop and when invoking it from C# code. :confused:

Let me know if you get Ubustream 2.0 working with VideoLAN 0.8.6.

I've been using the 0.8.6 beta with UbuStream 2.0 for some weeks (and the "official" 0.8.6 since it was released). So far - no problems (it seems to behave a little differently when playing in a minimized window, but that's a different issue).

[gnutech]

Are you testing with just one url or with several different ones? I'm working on MVP support for UbuStream list mode and I'm using a similar technique to wait for the file to be created before playing it. I'm testing with the Research Channel (pretty stable, reliable stream) and I find that using 5000 ms and 100 ms gives fairly consistent results. Some streams have a tendency to connect, start streaming for a second or two, then stop and refill the buffer before continuing to play. I'm wondering if this confuses the gbpvr video player since the file would show up quickly but would not have enough content for the video player to play. I don't know what values you have tried for these fields but, if you tried upping the second one from 100 ms to some really big number - a minute maybe - it would test this theory.

I have tried a couple of different url's. I settled on using the Research Channel stream because you seem to use it as your measuring stick. It is the stream that I have done most of my unsuccessful MVP testing with.

I'm also not sure whether there are additional timing checks in the MVP dongle code that affect this (especially since you don't experience the problem when using timeshift mode on the PC). One problem I have is that I don't have an MVP (although I've asked Santa to bring me one ) so I have, up to now, had to assume that if I can get something working in GBPVR's timeshift mode it will work for MVP users.

I hope Santa brings you one. It is the only way to go for me.

Well that's a good workaround. External Recorder "should" kill the vlc process once it detects that you have exited from the gbpvr video player. Also, it doesn't delete the output file itself but seems to rely on gbpvr's timeshift mode logic to do the clean up. So I'm still confused why this wasn't working properly for you. Also, I can't reproduce the problem you're having with the "allow only one running instance" preference. For me (using both 0.8.5 and 0.8.6) it seems to work as expected both when running vlc from the desktop and when invoking it from C# code. :confused:

Strange... Could you provide a screenshot of your working VLC settings?

Did you happen to see my post about using External Recorder with XMLTV, VLC Streaming, and RemoteTV? Do you know if Ubustream can do something like it or do you know of a setup that might?

Thank you for help and a great utility--Ubustream.

Respectfully,


Gary

[ubu]

It is the stream that I have done most of my unsuccessful MVP testing with.

LOL

I hope Santa brings you one. It is the only way to go for me.

I hope so too. In the meanwhile, I was hoping some of the "MVP experts" would chime in on this thread with suggestions to resolve your problem. Reading some of the other MVP threads, it does seem that the speed of transcoding is pretty critical and that running GB-PVR on a PC with a slower CPU can sometimes produce timing problems similar to what you are experiencing. What CPU are you running? Can you experiment with running GB-PVR on a faster machine?

Strange... Could you provide a screenshot of your working VLC settings?

The setting is very simple (especially for 0.8.5) so, to avoid storing yet another jpeg on the forum server, I'll describe it. In the VLC's Preferences dialog, I select the Advanced>Other settings from the tree and then check the Advanced options box at the bottom of the screen. I then check "Allow only one running instance" and click the Save button. (The only other option I have checked on the Other screen is "Use a plugin cache".) With this option set, the first time I open VLC it shows up on my desktop and, if I open VLC again, the same window remains on my desktop. With the option unset, the second time I open VLC I get a second VLC window on my desktop.

Did you happen to see my post about using External Recorder with XMLTV, VLC Streaming, and RemoteTV? Do you know if Ubustream can do something like it or do you know of a setup that might?

I've responded in that thread.

[gnutech]

I finally got it running over the MVP! As suggested, I cranked up the External Recorder wait time settings (10,000/10,000 seem to be the max) and it worked! It would be nice if one could enter a wait time setting greater than 10,000 to increase the total buffer volume. Also, you might suggest that new users start by maxing out the wait times in External Recorder.

With this option set, the first time I open VLC it shows up on my desktop and, if I open VLC again, the same window remains on my desktop. With the option unset, the second time I open VLC I get a second VLC window on my desktop.

I have the same settings you do. If I open an instance of VLC and then try to open another instance it only allows the single instance. However, when VLC is opened through the External Recorder and UbuStream that is when I experience the double VLC issue. A second instance of VLC opens and closes with the original VLC instance continuing to transcode.

With my work-around, this is a good enough solution for me.

Thanks for your help.


Gary

[groover km]

I have been playing around with this without much success I'm afraid - once it worked, twice I have got audio no video, all other times nothing...

Would someone mind posting their vlc settings for me to copy?

Thanks!

[ubu]

I finally got it running over the MVP! As suggested, I cranked up the External Recorder wait time settings (10,000/10,000 seem to be the max) and it worked! It would be nice if one could enter a wait time setting greater than 10,000 to increase the total buffer volume.

Excellent news!

If you edit the config-recorders.xml file in Notepad, you'll see these lines for each capture source:

<waitForFile>10000</waitForFile>
<waitAfterFile>100</waitAfterFile>

You can change the values to whatever you want. It's only the External Recorder config screen that restricts the values to some (arbitrary) maximum.

You didn't answer my question about the CPU you are using for GB-PVR but the long wait time you appear to need for MVP playback does suggest that more horsepower for the transcoding process might help.