Messages

Another thing I've just noticed...the OSD on the dodgy one is stretched vertically, compared with my other, working one! The Welcome menu is about 14.5 cm high on the dodgy one but only 12 cm high on the working one. I see the same expansion with the recordings menu and also the first Hauppauge boot screen! The vomp-MAC_ADDR.conf files on the vdr server are identical (one file copied over the other).

I'm starting to wonder whether these things are actually as identical as the labelling suggests...the outputs of dmesg are identical for the two boxes (apart from IP address and MAX address bits).

This sounds a bit like the topic:http://www.loggytronic.com/forum/index.php?topic=210.0

Hello,

I just recently got the news from the now available Beagle Board.
For US it is $150 and for EU it is currently €103,26 + import VAT taxes.

It is only the bord, so you need powersupply, a box, an IRDA receiver and network on top, but it shouldn't be to costly and involves for sure some practice in building it together.

What makes this board so interesting in comparision to other boxes (like the PopCorn Hour) is that it is fully open and even the drivers are available for HD.
For all other devices I have seen so far either no Linux driver exists or it is so much hidden in the security environment that no direct access is possible.
With HD I'm only unsure about the topic of encrypted data.

It can do only 720p, but personally I think this is enough for HD. I don't own an 1040p plasma.

What do you think?

@Lutz: I think i will give it a try.
@Chris: I want to let the signal go through a VPN . So i think i am safe. I can realize a line with 2Mbit/s or even up to 5Mbit/s in the Upload. Would that be OK for a nice picture? So the -s switches off the search for a VOMP-Server, right?

DVB-T doesn't have in average much more than 2Mbit/s per channel. So you could test this one and if unsatisfying use the 5Mbit/s (which is even close to average DVB-S).
Other possibility:
You may also check using a normal WebCam. Won't have normally 30pictures/s, but in case quality is not the important issue may be a better solution. See the VDR Wiki for possible solutions.

Hi Lodda,
I think the PVR 150 or 250 will also do the job, they encode and do not decode I think, they are missing the hardware decoder, but they both transform a video stream to mpeg which can be used by vdr...
Lutz

Ups, sorry you are right. I mixed that up. So all PVRs should do the trick.

Regarding getting the cam signal to VDR:

For this you need a card like the Haupauge PVR 350. This encodes in live an analog signal into an MPEG stream and the PVRs are supported by VDR, at least mostly.
I have one, but never connected by digicam to it.
The PVR 350 and 500 are fine (maybe newer ones as well), but not the 150 or 250. They can only decode, but not encode.

The remaining (getting to the internet) is then another task - i.e. with regards to security.

____

Correction: I mixed that up. All PVRs can encode, but only the 350/500 can decode.

Hello,

I have Live-TV now working. Yeahhh

Working means:
Output of video and audio, but for sure it is not yet everything you can think about as a TV application.
Attached is a screenshot. I will remove it later again, when the app is more mature. Screenshot removed

I have also uploaded the sources to a repository: http://code.google.com/p/qtvomp/

Papablues:
Next is now the change to a synchronuous class, so maybe with this approach you will get it to work on MacOS.

>If anybody is interested in the code, I can post now. But would be good to have a host...
*JUMP* *ME*

I'd like to see if there is a chance to get that thing running in MacOS.
Got a MacBook Pro and a Mac mini at hand, so i could give it a try.

What a perfect match. I can test Windows and Linux, but don't have a Mac and I wondered if it will work on Mac as well (as the trolls said/promised).

I will cleanup a bit and send you the gzip package till it's clear where and how to host the code. Please send me your email address in a PN.

For the moment you will need to adjust the pro files manually as I don't have yet checked the details too much of setting it up in a general way. I just aligned it to work on my disti (Debian Experimental/Lenny).

And there is also the issue I had with the backend phonon-gstreamer. This didn't work at all and maybe therefore the issue is equal also with the MAC phonon-BE (it's the difference in having the data stream synchronous to the request call or asynchronous and phonon-gstreamer-BE only supports synchronous).

I know a workaround (some code to be exchanged), but that would mean having the datastream synchronous. Sadly, at the end gstreamer still cannot play the recordings (I tried with Totem) and so even if I support asynchronous for gstreamer, I still cannot use it. Only Xine-BE is playing recordings and also supports asynchronous data streams correctly (as defined in the docu).

In case gstreamer will support playing the recordings in future, I may switch to synchronous datastream, so no dependency on KDE on Linux, but it can also be possible that phonon-gstreamer will support in future asynchronous datastreams (I sent a bug/wish report to the trolls as well as an KDE dev).

Another issue:
Are you able to play the recordings on MAC with Quicktime (or whatever the MACplayer is) as they are stored by VDR?
If not, there is no chance to play recordings... Live-TV is different and cannot be tested before I implemented the functionality.

Update to current status (not that anybody thinks this is vaporware )

Yesterday I got the first recording video played in my application. For me this was milestone 3.

Details why it took so long:
At the end it was clear it is a bug in the phonon-gstreamer implementation, or better a not any longer supported function. During trying to find the issue, I cleaned up all the structures of my first version, so I'm now at a point where I can clearly look foreward.

Things done:
Login, menu, recordingslist, mediafilelist, play media (which is currently MP3 only, no JPeg yet), rudimentary play recording (just play, no stop, jump, etc.)

Things open:
Live-TV, channellist, timers (list and set), epg
i18n, config settings, overall look of the app, etc.

If anybody is interested in the code, I can post now. But would be good to have a host...

Maybe I got your question wrong.
I think you mean you have a normal 0.2.7 server and want to try the current dongle / client 0.2.8rc1 out of cvs.
Also the other way round 0.2.8rc1 serverplugin and 0.2.7 client.
Both for sure won't work, as the network protocol has changed fundamentally.

But I also have only 1 productive server. I managed the trick with another server in a virtual machine which gets all data from the normal server via streamdev-plugin. The server in the virtual machine has now the vomp-plugin from 0.2.8rc1.

I described already my setup in this forum.

Works like a charm. No problem with the family and also full flexibility for development.
Only negative sideeffects are:
- Switching channels is a bit slower (as it needs the roundtrip through streamdev-plugin)
- Live-TV and recording a program is not possible, as streamdev is 1 channel only at the same time
Both are not a problem for a dev environment.

Dito for me. Two D3A are running just fine.

If there aren't any translation files, you just won't be able to select any language other than english.
So this is not the issue.

When I get a "channel unavailable", the OSD keeps showing with a black background. So far ok.

But if I then press back, the OSD is removed and I get a black screen.

If I then press "back" again, I come back to the channellist.

This black screen in between is a bit confusing as it rather looks like the box has crashed (which is not the case here).

This happens with TV as well as radio.

muellerph:
The java remote simulator is sending the wrong codes for the old remote, that's why I had it the wrong way around. Can you try the code now, I think it might do what you  want.

Yes, works now again as expected. Thanks.

@muellerph:
I am guessing you are using an old style remote? I seem to have lost mine, so I am slightly in the dark. Are you finding that up and down are scrolling the now/next data rather than changing channel?

Yes I have 4 MVPs and 5 old remotes.
The other way round. I can change the channel, but not scroll the now/next data. Would be good to have some keys to use here as I found it useful.
The old behavior was: When now/next data was shown, the up and down was scrolling through them, when there was no now/next it was switching the channels.

Version info in the protocol: Yes, but I'm not sure about doing it for this version. Fear not though, while this release has taken so long because of the enormous change to the protocol, there is no such blocker for future releases, so they can progress much faster. The same goes for scrolling of EPG descriptions.

I was thinking of it and the more I think about it, it should just be an attachment to the name the server sends back when doing the UDP broadcast. Just add 6 digits in brakets which could send the versioning info. I don't think this string needs to be overengineered. So something like "vdr (000208)" for the 0.2.8 could be the answerstring from the server. Future clients would be able to read and compute it, old would just display the version in brakets additionally. Just the server would need to be updated for the moment, the client can use the info in a later step.

@davep:
Confirmed. It will be due to my latest BoxStack update. I will look at that next.

I can confirm as well. I had 0 timer entries.

Compiled and started fine.

Random issues:
- JPEG showing works, but if I press back box hangs, seems to be same issue as with MP3 - also mentioned in Vomp-Media-Player thread
- Previously it was possible to scroll in live TV through the epg with up and down for the next entries. Is this still possible and in case yes which keys to use?