UbuStream design issues and wishlist

[ubu]

I'm starting this thread as a place to discuss various issues regarding the design of UbuStream and its feature set. That way, the support threads (and beta test threads) won't get clogged up with these discussions (which can get rather lengthy ).

This is also a good place to put feature requests so I can keep track of them.

[ubu]

• When using the internal player, a message showing buffering progress would be useful feedback that something is actually going on. (The internal player splash image was funny at first, but I think seeing it all the time might get on the visual nerves! ).

I actually tried to put a large progress bar over the internal player full screen image (like I've done with the volume level bar) but hit two stumbling blocks. Firstly, the progress bar was interfering with the player control. I haven't had time to sort out why this happens. Secondly, most stations spend most of their time "transitioning" (ie. connecting to the server and locating the stream) and relatively little time actally buffering, so the progress bar wasn't very helpful. So, for now, I've shelved it in favour of higher priority items.

The "Bill Gates as Fuhrer" image while buffering in the WMP control was a little joke for the beta testers. The "official" release will have a WMP Vista image instead, so it will look much like the other internal players. For me, the player logo works well as an indication that the player is still there but not actually playing anything. (You'll notice that it appears when you pause or stop the stream as well as when it is "buffering").

• When starting up Ubustream Config for the first time, there's no feedback that anything is going on. A new user might be tempted to click on the config several times (as I did - on than one occassion) since the panel can take a long time to appear (internet connection related?)

If you start with no Ubustream.xml database file (ie. completlely clean), a message box pops up to inform the user which players have been defined but don't seem to be installed on their system. I've enhanced this to be a slightly more fancy dialog that also informs them that the database is about to be initalized (so they'll know what's going on). I'm in the process of enabling a similar dialog for users who are upgrading, warning them that their database is about to be converted to the new format (also gives them a chance to cancel out so they can take a backup of the Ubustream.xml file if they want).

• If the autosynch button remains, some form of progress indicator would be useful (eg which group is currently being scraped / how many to go). (Thanks for the standalone update app.[ATTACHMENT NOT FOUND] Haven't tested it yet on my production system yet, since the app needs 2.1. Wiki notes forthcoming!)

Why wouldn't the AutoSynch button remain? Not everybody is a news junkie, like you, that needs a refresh (fix?) three times a day.

Most of the DynSource apps I use (or, at least, have configured for AutoSynch) run fairly quickly, so I find the button useful. I am, however, thinking of removing the "AutoSynch at startup" option since, if one of the apps throws a really evil exception, it can effect the GB-PVR startup. Also, the new standalone app combined with the scheduler can be used instead.

Two reasons why I haven't provided any progress indicator for DynSource downloads in the plugin UI. One is that I run the AutoSynch task asynchronously so the user can continue to use GB-PVR while it's running. (You can watch a video or check the TV Guide while you're waiting), so the main thread doesn't really know how far the task has progressed. The other is that arranging dynamically changing screen content involves a some tricky coding due to GB-PVR's screen rendering cycle. So, I tend to avoid it where I can, adhering to the KISS principle. I'll give it some more thought though.

• I like the prev-next group buttons. I like to scroll through the titles within a group to see what catches my eye. V2.1 doesn't let me do this anymore without having to press several more remote control buttons. Please, please bring this back.

OK, OK, I'll put it back! I didn't think anyone was using those buttons. I could put back the logic but just support the Next/Prev buttons on the remote (ie. no extra buttons cluttering up the menu) or I can put back the whole thing, including the menu buttons. What do you think?

I took the buttons out because I was trying to avoid scrolling menus (since they tend to confuse people) but I guess I'll end up adding more buttons for something in the future anyway. I can't think of a good alternative.

• The details screen is nice. What I think would be nicer is a pop up that appears showing the description of the webstream, so that as I scroll through the titles, I can see what the clip is all about. The present solution of selecting the item and then selecting the player/timseshift requires backing up to get to the next item - several more button presses on the remote control. The same popup could display a jpg image (I'm working on a prototype, but progress is slow, starting from a zero knowledge base of C# and writing GB-PVR plugin apps, I may get nowhere fast - or at all )

Well, this issue seems to have its own thread now so I'll respond there. Your "proof of concept" stuff looks good.

• What would also be nice is an extension of autosync to allow downloading and caching of favorite dynsource groups (in my case, news and current affairs) at regular intervals. Perhaps this is something that can be done in channel mode. I've never tried channel mode.

Do you mean caching the links or actually recording the streams to disk.

To achieve the former, you can simply create a new group and add the streams you want to save to it. (The DynSource update won't delete stations that are also being used by groups other than the DynSource section group.) I guess this could be automated for specific DynSource sections.

To record the actual streams would involve using Timeshift mode (so the streams must be VLC compatible). Right now you can use Record, Snapshot or GB-PVR scheduled recording (via Channel mode) to record a single stream. I haven't been able to get VLC to record multiple streams from a playlist at the same time. It just stops transcoding after the first playlist item. So, right now, recording a group isn't possible. You can play a group, just not record it (or play it in Timeshift mode). I need to investigate this further because it would quite useful for other uses too. I haven't had a chance to try using alternative transcoders (mencoder, native ffmpeg) or to explore other approaches with VLC (spawning multiple VLC jobs that all use the "append to output file" VLC option, for instance).

[ralphy]

OK, OK, I'll put it back! I didn't think anyone was using those buttons. I could put back the logic but just support the Next/Prev buttons on the remote (ie. no extra buttons cluttering up the menu) or I can put back the whole thing, including the menu buttons. What do you think?

Maybe skip and prev on the remote?

Do you mean caching the links or actually recording the streams to disk.

I was actually thinking of the streams. I see ninemsn have recently(?) added podcast streams, so I might be able to use the dynsource concept with dynsourceupdate to save the stream to the recordings or video folders. Otherwise, sounds like using Timeshift or Channel mode GBPVR recording.

[ubu]

I see ninemsn have recently(?) added podcast streams, so I might be able to use the dynsource concept with dynsourceupdate to save the stream to the recordings or video folders. Otherwise, sounds like using Timeshift or Channel mode GBPVR recording.

Well, sounds like there might be an opportunity to do something to integrate this kind of caching for DynSources but, in the meanwhile, have you tried using the Podcast DynSource for this. I've only used it for audio podcasts so far but I don't see why it wouldn't work for video ones.

Here's how I use it. I have my Podcast receiver (Juice, in my case) set to automatically download the podcasts I specify to a podcast directory. It creates separate sub-directories for each podcast source and downloads mp3 files to them. Then I specify the podcast directory in the UbuStream Options panel, restart the config app so it will enable the Podcasts DynSource and then configure the DynSource (choosing the podcast sub-directories I want to use as "sections"). Then, each time AutoSynch is executed, it creates groups based on the podcast sub-directories and stations pointing to the mp3 files (which can then be played using any of the player options). The station name and description are read from the the mp3 file's ID3 tag

If the video podcasts download mp4 files (or anything that's compatible with the media players being used), that should work the same way.

EDIT: I notice ninemsn gives you the option of downloading either mp4 or wmv files. I think the BBC podcasts use mp4.

[ralphy]

I've only used it for audio podcasts so far but I don't see why it wouldn't work for video ones.

Indeed ninemsn video podcasts work too!


On to the wish...

I know that the advance settings in the stations can be used to set up the recording parameters, but this doesn't seem ideal for dynamic sources. Is there a way to set up defaults for the dynamic source? Right now, I seem to get '0 minutes' as the default time to record.

[ubu]

On to the wish...

I know that the advance settings in the stations can be used to set up the recording parameters, but this doesn't seem ideal for dynamic sources. Is there a way to set up defaults for the dynamic source? Right now, I seem to get '0 minutes' as the default time to record.

All new stations get a default recording duration of 0 minutes (not just DynSource ones). I could change it to some other value. What do you think would be a reasonable default? 60 minutes maybe?

[ralphy]

What do you think would be a reasonable default? 60 minutes maybe?

Sounds reasonable. I assume that if the stream is less than the time allocated, presumably the recorder stops? Maybe the default time could be selected as by the user in the options panel.

[ubu]

Sounds reasonable. I assume that if the stream is less than the time allocated, presumably the recorder stops? Maybe the default time could be selected as by the user in the options panel.

Ok. I've changed the default recording duration for newly created stations to 60 minutes. I agree that, ideally, this default should be configurable on the options panel but, since this would involve changing the database schema (yet again ), I'm somewhat averse to adding this feature right now.

EDIT: And, yes, the recorder will stop if the stream ends before the specified duration. The recording duration is really only needed for recording live streams, which potentially could keep on recording until your hard disk is full. An arbitrary cap on the recording time seemed like the only way to avoid that.