New and improved UbuStream web tv/radio "tuner" - now released as a plugin

[ubu]

My idea for making it "extensible" is working with plugins for the viewer-plugin: We define an interface-class. Each extension (e.g. a CNN-parser) is a seperate dll that implements that class. The viewer-plugin looks in a directory for plugin-plugin-dll's and shows a name per dll to the user. When the user selects this name, the viewer, gets the URL's by getting data from the class. At that moment, that plugin-plugin gets the data from the website (e.g. CNN) and parses it to URL's that are returned to the viewer-plugin.

I hope my explanation is clear. I made a little prototype in GB-PVR and i'm sure this will work.

So, what you describe is a completely new plugin. It's not clear to me (from your description) how this would interoperate, integrate or share resources with the UbuStream plugin. You don't mention the issues I raised in my previous post.

I'd like to give my idea a try. Ubu, is it possible you share the source-code for your plugin with me. Then i'll try to extend it with a plugin-structure.

Unfortunately, much of the code for UbuStream is shared with another (non GB-PVR related) proprietary product, UbuRemote, so I am unable to publish the source. If there are specific techniques you are interested in, I might be able to help. But, if you are using the approach you outline, I'm not sure how the UbuStream code would be relevant. As I said in my previous post, I'd be willing to create a "custom" version of the UbuStreamCmd.exe component so you could provide support for alternate media players (and open up the possibility of support for MVP users).

[HTPCGB]

I'm glad that you're interested, here are my opinions.

1) The UbuStream paradigm is a simple list of stations, each representing a stream. (In the next release these may also be organized into groups/playlists). The user can "cherry pick" the streams they want to include in the list. The station title (entered by the user) is the only information displayed for each stream. The CNN plugin (or any site specific plugin) would, presumably, need to organize the streams differently, based on the list of streams provided by the target site, and display additional information (description, date, etc.) for each stream.

Some sort of grouping system would definately be required. Most websites will probably have a group of sections and then a group of streams within each section. Most likely three levels of selection would be required.
-the master list of individual stations and websites
-a section list for that website
-the streams within that section

2) What is the UI that the user sees when playing a stream? UbuStream simply provides a GB-PVR shell which invokes a media player to play a stream and the plugin assumes the user has configured their remote control to send commands to the player in addition to GB-PVR so the flow of control is relatively seamless. The CNN plugin (as I understand it) displays a form with WMP embedded within it that overlays the GB-PVR display (not sure how the remote control talks to it).

I dealt with the remote control issue by making the videoplayer overlay appear as "GB-PVR" to the remote control program. It's rather inelagant but it requires zero configuration on the user's part. The only issue is that the overlay is not skinnable and looks quite ugly.

Personally, I like solution number 2 the best. It seems pretty simple for Ubustream to call an .exe file, which would then produce an .xml or .pls file. (Enclosed is a sample .xml file for the cnn website. How difficult would it be to create a selection list from it?)

As for MVP support, wouldn't it also be possible to use the above method for transcoding to MPEG?

[ubu]

I'm glad that you're interested, here are my opinions.

We seem to be on the same page. I think this could work (if we resist scope creep ).

Some sort of grouping system would definately be required. Most websites will probably have a group of sections and then a group of streams within each section. Most likely three levels of selection would be required.
-the master list of individual stations and websites
-a section list for that website
-the streams within that section

The upcoming release of UbuStream will only support two levels (ie. Group and station within group). For now, this could be solved by combining the website and section names (eg, groups titled "CNN - World", "CNN - US", "CNN - Law", etc. would each contain a list of stations titled "Quake victims mourned", "Deadly plane crash", etc.). For a more sophisticated UI, we could revisit solution number 3 in my previous post.

I dealt with the remote control issue by making the videoplayer overlay appear as "GB-PVR" to the remote control program. It's rather inelagant but it requires zero configuration on the user's part. The only issue is that the overlay is not skinnable and looks quite ugly.

Interesting. Do you use "GB-PVR" in the overlay form's title bar to force irremote.exe to use the GB-PVR section in irremote.ini and then expose the same keystrokes as GB-PVR?

Personally, I like solution number 2 the best. It seems pretty simple for Ubustream to call an .exe file, which would then produce an .xml or .pls file. (Enclosed is a sample .xml file for the cnn website. How difficult would it be to create a selection list from it?)

The xml file looks very straightforward. I'm currently planning to support pls and m3u formats and would like to avoid proprietary xml formats so a file in one of those formats would be best. In addition to "on demand" imports I'm trying to build in a "dynamic import" capability which would synch up the UbuStream database with external sources each time the UbuStream display is refreshed (or at least fairly frequently ). I've got this working with a pls format stream which is triggered by making a request to an url. I save the stream to a temp file and then import it. It would be fairly easy to add the option of calling an .exe to create the temp file instead. The CNN plugin (or "mini-plugins" in general) would be responsible for storing any user filtering preferences for the data placed in the file ("Only pick streams from these sections", "only pick streams newer than this time", or whatever).

As for MVP support, wouldn't it also be possible to use the above method for transcoding to MPEG?

If the streams will play OK in VLC (and I think they will) users can configure UbuStream's channel mode to play the streams in GB-PVR's timeshift mode (which will record the stream to a temporary MPEG file) allowing MVP users to watch it. The problem is that they would have to do this setup for each stream, which is a big hassle for something which is essentially a "throw away" stream. I'll have a think about it. If you take a look at the ExternalRecorder plugin and then read the UbuStream documentation for channel mode setup, you'll see how this all works and where the problem lies. Hopefully one of us will get an idea for a solution.

If you want to discuss this in more detail, maybe email me (available in my Members List profile). I'm going out of town on Friday for 2 weeks so, if you don't get a reply straight away, that'll be the reason.

[HTPCGB]

The upcoming release of UbuStream will only support two levels (ie. Group and station within group). For now, this could be solved by combining the website and section names (eg, groups titled "CNN - World", "CNN - US", "CNN - Law", etc. would each contain a list of stations titled "Quake victims mourned", "Deadly plane crash", etc.). For a more sophisticated UI, we could revisit solution number 3 in my previous post.

Agreed.

The xml file looks very straightforward. I'm currently planning to support pls and m3u formats and would like to avoid proprietary xml formats so a file in one of those formats would be best. In addition to "on demand" imports I'm trying to build in a "dynamic import" capability which would synch up the UbuStream database with external sources each time the UbuStream display is refreshed (or at least fairly frequently ). I've got this working with a pls format stream which is triggered by making a request to an url. I save the stream to a temp file and then import it. It would be fairly easy to add the option of calling an .exe to create the temp file instead. The CNN plugin (or "mini-plugins" in general) would be responsible for storing any user filtering preferences for the data placed in the file ("Only pick streams from these sections", "only pick streams newer than this time", or whatever).

Enclosed is a sample .pls file. (Which to my understanding is pretty much the same as an .ini file.) I was thinking of having things set up in the following way. The user enters the desired title for the section that they desire (e.g. CNN - World), then they point ubustream to the .pls file containing the streams and after to the .exe that will update the .pls file. The problem I see with your proposed method is that the mini-plugin executable will produce several seperate playlists simultaneously. If the ubustream plugin can't communicate with mini-plugin, how will it know what to put into the temp file?

If the streams will play OK in VLC (and I think they will) users can configure UbuStream's channel mode to play the streams in GB-PVR's timeshift mode (which will record the stream to a temporary MPEG file) allowing MVP users to watch it. The problem is that they would have to do this setup for each stream, which is a big hassle for something which is essentially a "throw away" stream. I'll have a think about it. If you take a look at the ExternalRecorder plugin and then read the UbuStream documentation for channel mode setup, you'll see how this all works and where the problem lies. Hopefully one of us will get an idea for a solution.

I still need to catch up on my reading.

Regards,
HTPCGB

[ubu]

Enclosed is a sample .pls file. (Which to my understanding is pretty much the same as an .ini file.) I was thinking of having things set up in the following way. The user enters the desired title for the section that they desire (e.g. CNN - World), then they point ubustream to the .pls file containing the streams and after to the .exe that will update the .pls file. The problem I see with your proposed method is that the mini-plugin executable will produce several seperate playlists simultaneously. If the ubustream plugin can't communicate with mini-plugin, how will it know what to put into the temp file?

The pls file looks fine. The new import function in the UbuStream beta reads it OK and puts it in a group called "CNN - World".

To integrate this into UbuStream so it's a bit more useful, I'm thinking of offering users the ability to define "Dynamic Groups", each one associated with an application (with optional parameters) that would create the pls file. Each time UbuStream was loaded it would fire off each of these applications and import the resulting pls file into the associated group.

For instance, a dynamic group called "CNN - World" might be associated with the application CNNPlaylistGet.exe with the parameter "CNN - World". When executed, this would create the file CNN - World.pls which would then be automatically imported into the CNN - World group. (Alternatively, instead of passing a parameter to a common app, separate apps for each group could be used: eg. CNNWorldPlaylistGet.exe with no parms. As long as the command produces a file with the same name as the group, it shouldn't matter how it's implemented.) This seems the simplest approach. If you still prefer the idea of a single app which would generate multiple playlists, they could be written to a single file but with the group name embedded in each "Title" line (that's how the Worldwide Media Project interface to UbuStream works, for instance) but it does add some complexity and it makes the pls file "non-standard" (Do we even care?).

Also, when defining each "Dynamic Group" users would specify if they want the import to be destructive, replacing all streams in the group, or non-destructive, appending the new streams to the group. In either case, they would be able to delete individual streams once they had finished with them.

Hope this makes sense. If there's anybody else who a) likes the sound of this idea or b) might be interested in writing a mini-plugin playlist generator, please chime in.

[HTPCGB]

G-mail balked at my attempts to send an .exe. Here it is instead.

[ubu]

G-mail balked at my attempts to send an .exe. Here it is instead.

Works fine. We're getting there.

I've started a new thread for "mini-plugin" discussions in the UbuStream support sub-forum:

UbuStream Dynamic Source "mini-plugin" architecture for on-demand streams

I have started the ball rolling by publishing a description/definition of the new architecture as it will be implemented in UbuStream v2.0. (I actually have most of it working already ). You will notice a few minor changes to file format and naming standards (sorry :o). Thanks, btw, for all your help in turning this from a vague notion to a concrete reality in such a short time.

If anybody else is interested in this new capability (Remco?), please check out the write-up and post comments/suggestions there.

[Remco]

If anybody else is interested in this new capability (Remco?), please check out the write-up and post comments/suggestions there.

I'll give it a try for Uitzendinggemist (a Dutch site which streams shows that have been on TV last week)

Personally, i would prefer exchanging data via classes in dll's instead of via .pls/.plx-files. Currently i've got a prototype up-and-running of a webvideo-plugin that uses dll's for specific website-parsers.

[ubu]

I'll give it a try for Uitzendinggemist (a Dutch site which streams shows that have been on TV last week)

Personally, i would prefer exchanging data via classes in dll's instead of via .pls/.plx-files. Currently i've got a prototype up-and-running of a webvideo-plugin that uses dll's for specific website-parsers.

That would be great. The more mini-plugins that are available, the more likely people are to use this feature.

I've responded in greater detail to your post here in the Dynamic Source mini-plugin thread (so other interested parties can follow the discussion).