Messages

It is, it should! Does it not?!

agebel:

Yes, radio support is soon. I am currently working on improving the GUI internals and then I think I will tackle radio support. The problem with radio is that the audio chip seems to eat all the data instead of allowing some buffering. Otherwise it would have been done by now, most of the code is there and waiting to go.

If anyone wants to have a look at the audio chip eating all the data instead of buffering, please do... I think it could be something to do with the sync ioctl which I don't really understand fully yet. Maybe a look into mvpmc to see how it does it might do the trick...

Hi, my focus is the set top box functionality. Other media on the MVP is not too much of a priority for me at the moment. I guess it will fall into place at some point when the foundations are a bit more stable.

As for the current roadmap, I am finishing the list of "musts" for a system that warrants a version 0.1. After that, I will write a new roadmap

Hello, about long summaries, yes that is a new bug. I have never personally seen a summary that goes over the length, on the other hand I don't use it very often

The resume option is under discussion in another thread. Something will change..

If you have a new remote, and you have set the type to new in the options screen then channel hopping should be unaffected by the banner. Up channel button should change channel even if the live banner is there.

I have no idea about the sound problem. I am having some trouble with the sound chip myself at the moment, after I have fixed that, see if the problem still exists.

Ok, the 6 seconds too early thing is because that is how far ahead the demuxer is from the stuff being played with the video chips. (Should be a lot lot closer for live tv as I still havn't got prebuffering working!)

The demuxer detects the change in aspect ratio and sets the format for the TV. Then the data goes into the buffers waiting to be played. The solutions are not exactly pretty. First off we could have smaller buffers for recording playback. That would shorten the time but not get rid of it. Secondly, I could set some kind of timer to change the aspect later, but a) wouldn't know exactly when to set the timer for, would just have to guess, b) how to destroy/modify the timer if the user navigates around inbetween the timer being set and it acting. That's why I left it as it is for now..... I think it's something I could write better later, because later we might have timecode detection in the MPEG data, in which case setting the timer for the right time would be solved. Later I might have written a timer system for events... That would also be a fairly important pre-requisite to setting a timer!

As for exiting the options screen, the only thing I can do about that is to detect whether the widescreen format was changed or not, and if not, then not do the reinit of video. The problem here is that re-setting the aspect ratio requires closing the file descriptor to the video chip, which in turn causes the aspect ratio scart line to revert back to 4:3.

Dongle 0.0.11 is my second attempt at widescreen support. (Not having a widescreen TV myself makes the process slightly more tricky.) Please refer to the other poll post to see what should work and what shouldn't. So, is it better now?

Another go at widescreen. I think it should work this time, and should also always fill the screen with the menus too.

Yes, actually I've just had an email from Dave about this. I am currently planning a bit of a GUI rewrite, so I don't want anyone to waste time in the code at the moment, but after that I think we should all plan a translation system for it.

Normal is 4:3
Widescreen is 16:9

---------------

The new widescreen support is supposed to enable:

Viewing a 16:9 programme on a 16:9 TV
Viewing a 4:3 programme on a 16:9 TV

An extra complication when the TV is 16:9 format is that the TV needs to know the aspect ratio of the incoming picture in order to stretch / squash / display it properly. For correctness, the TV should be informed the aspect ratio and do the following: When the picture is in 16:9 format the TV correctly displays all the picture over all the screen. When the picture is in 4:3 mode the TV should display black bars at left and right of the picture, the 4:3 picture will be in its correct aspect ratio in the middle of the screen. (I realise most people will then get their TV to strech/zoom a 4:3 picture to fit, but that is not relevant here. The aspect ratio information still has to be present even for that to work properly). On SCART TVs a SCART control line can be used to tell the TV the incoming aspect ratio. This poll is basically, does this work?

Also, to any American users (Hoochster!).. How is this widescreen switching done for you? As far as I know there is no system of sending control signals through composite signals, S-Video signals, or seperate RGB cable signals.

---------------

The new widescreen support has nothing to do with:

Viewing a 16:9 programme on a 4:3 TV

Viewing a 4:3 programme on a 4:3 TV has always worked. Viewing a 16:9 programme on a 4:3 TV -- currently the sides are chopped off and the middle of the picture is drawn on all of the TV screen. The other way to do this is to letterbox the picture with black bars at top and bottom. Unfortunately, while the MVP will letterbox a picture, it then draws the picture at the top of the screen with all the black bars at the bottom. If anyone fancies playing with ioctls etc to try to guess-fix this, be my guest.

Widescreen! Well, maybe. I don't have a widescreen TV so I can only guess. You tell me if it works! You will have to go to the options menu and tell it you have a 16:9 TV. Then, on scart systems, when it is playing video it should start switching your TV for you between 4:3 and 16:9 incoming signal aspect ratio. (I might have these the wrong way around... ) Unfortunately it will switch the size several seconds too early, but this is a problem for later.

A crash/segfault when watching live TV and VDR starts a recording from another mux thus killing live TV for the MVP has been fixed.

Show FTA channels only patch added, thanks to davep for that one. You will need to update your vompserver plugin for this one, but please wait a few hours after this post because SourceForge anonymous access CVS has a delay. There is no problem with running the new dongle and the old vompserver plugin.

And in the more technical department...

Makefile for client edited for a new -DDEV define, and fixed the compilation parameters for releases.

Nothing can be saved at the MVP, there is no storage. But, the vompserver does keep a seperate configuration file for each MVP (by IP address) so resume points will be different for each client MVP.

I think Dave's suggestion is good too. The client could get the resume point data when you press ok on a recording - just before the recording menu appears. If there is a resume point it could pre-select the resume option. Thoughts?

Actually here are the changed files.

Hi, glad channel listing is fixed. Unfortunately the public access SourceForge CVS for vompserver hasn't caught up yet with the new stuff. It should be there in the next hour or so I think. That will fix the guide problem.

In this dongle:

One of two remaining known picture corruption bugs fixed
Channel up/down buttons on new remote in live tv work
Banner on live tv now has 24 hours of schedules for current channel
Programme summary information for any listed programme
Hopefully fixed slow channel listing bug

And from a technical point of view, data structes are now converted to STL.

You will need to update the vompserver plugin for this dongle. (It seems to not-crash if you don't update it, but I wouldn't recommend this!)

I think I know what is happening with the long channel listings. If I'm right, it's a printf line I left in the program by mistake for dongle 0.0.8 - it seems that if the program is started by init and friends, and then it starts printfing lots, at some point it pauses for a while. It should only happen the once I think, further channel listings should be quick. Which I think is what you are saying AronSira..?