Messages

Ok, then I will not introduce any more hassle with protcol version numbers etc.; BUT as we are changing protocol now, would it be a good idea to introduce some new fields that are already present in VDR but are not used in vomp, like:
-preferred menu language
-preferred audio languages
-preferred subtitle languages
-timer margins (now a setup item in vompclient, but could be simply copied from VDR).

since it makes no sense to have these variables setup differently from VDR.... What do you think? And if you agree, where would be the best place in de protocol to send this data (somewhere in the "connected, loading config" part of the conversation).

I have a headless server, so I'm not using VDR settings and/or having easy access to change the vdr values.
So whatever you want to add, please have it accessible via Vomp as well.

And only the defaults are taken from vdr settings.

For the language it may be useful in rare cases to have it differently by client. E.g. you a have an au pair women or are living in a shared flat with different students.

Best place is when loading menu languages as is today.

I'm also missing following line for the processGetChannelSchedule

thisEventSubTitle = event->GetSubtitle();

It is in the block "#if VDRVERSNUM < 10300", but not in the block of the newer version. There it is only:

thisEventSubTitle = NULL;


For sure not yet used in VOMP client, but I would like to have it in QtVomp.

Thanks for the hint. That's what the alpha is for, getting the glitches clarified.

For the Makefile issue:
To be honest, I have not much experience in doing the makefiles, so in case we have customized environment, I'm a bit lost what to do.

But so far, there should not be the need to adjust the Makefile, only the qmake ".pro" files need to be adjusted.
For Linux, the respective .pro settings are in the file "src/src.pro".

Maybe I will switch to cmake, but also there no experience on my side.

So the patch you have to apply it to CVS version and then recompile it?

No, there is no patch for 0.3.0 or current cvs available yet. Did you read the other thread I mentioned?

If yes, I do not have a machine for compiling vomp. Is there any ready compilled version even for 2.7?

Yes you said so already. But there is no precompiled server side version available (not that I'm aware of for Debian and my server is Debian as well).
The client is compiled available, but not the server side.
And without the server side, the client won't work (different network protocoll for media data).

On the other hand it would be nice to have it on 0.3.0 for the reason 0.3.0 version is mutch more stable on LiveTV instead of 0.2.7.

And again: Did you read the link I gave?
avvdr stated that he will do so, but it is not ready yet.

0.3.0 doesn't play any MPEG2 beside of the normal recordings of VDR.

There is a patch for Vomp 0.2.7 which has not yet been adjusted to 0.3.0.

So either you need to go back in to version 0.2.7, apply the patches for server and dongle (which you said you cannot do) or you need to live for the moment without this functionality. See also http://forum.loggytronic.com/index.php?topic=248.msg2478#msg2478

Hi,

this looks strange.
When JPGs are displayed, the files should be played as well.
- What is your server version? Is it also the plain vanilla one?
- Are the MP3 files displayed?
- The files are identified by the extension, what do they have (supported are ".mp3" and ".MP3" )?

Thanks for all the comments.

1. Coded channels..

Some times it takes a few seconds for the stream to start working.  In normal vomp the picture starts when it's available.  On qtvomp we get the audio but no picture.  If you click back and then play again the picture comes in.  Can a quick check loop be introduced to check for the start of the stream?

I've seen this as well, it only happens sometimes. But I have no clue atm what triggers the delay, so it maybe my code, the phonen libs or Xine.
Rough guess atm is that Xine introduces the delay, when it starts loading/initializing the demux libs.

2. Audio channel.

I'm an Engish expat living abroad.  I'd like to change the audio channel when possible.  Could this be possible?

Somehow good and bad news:
First the bad: There is no support in Phonon on subtitles, audiostreams, etc. at the moment, so I have no chance to change e.g. the language at the moment.

Somehow good:
The VLC-MPlayer-Backend is developed currently outside of the phonon repository. Within these new backends, the author has implemented the support for it within Phonon.
He also stated to want to move these backends into the main phonon repository for the next release (which will be within KDE 4.2 in ~January). But till today I haven't seen this happening. I'm also unsure if the Xine backend will then also support this functionality.

So when KDE 4.2 comes out (which then will be Phonon 4.3), I can hopefully add the support for the mentioned functionality.
Next timeslot would be Qt 4.5.

Now I have it working.. 

I miss my channel numbers.  We have nearly 5,000 channels, so have seperated them into channel blocks.  Consquently I go to things like channel 1205, or 1414 etc.  Anyway to do that in qtvomp?

Radio is missing..

Both will be in next version. Rather easy to implement.

Never thought about having so many channels.

[4.0]

        libphonon.so.4 => /usr/kde/4.0/lib/libphonon.so.4 (0xb7e81000)

This looks like Phonon < 4.2.
Phonon 4.2. was shipped with KDE 4.1.
In KDE 4.0 the version had issues i.e. with the videowidget. And that's what the issue looks like
"_ZN6Phonon11VideoWidget5eventEP6QEvent"

So it seems it uses an older version of Phonon on your machine.

Please run

  ldd ./qtvomp

and to see what is missing.

Isn't it "-s"? Or is that an earlier version of the code?

You are right and for me a brown paper bag.

-p was the first version, later I switched back to the same as vomp uses.

Chris,

may you update/fix the announcement?

The README is correct, but in the announcement it is wrong.

How about using the normal ip-address?

e.g. ./qtvomp -p 192.168.1.1

(I haven't tried the localhost address at home, but know the 192... works).

Maybe a firewall is also blocking the port (but this would look strange to me).

Use the -p <ip-address> command line option when starting qtvomp.

update:

use the ip-address directly, not the name, as it doesn't resolve it.
./qtvomp -p 127.0.0.1

This is a limitation of vompserver at the moment (it blocks the port and only answers on this port).

No workaround possible from my side (at least not that I'm aware of).

Ok, now rethinking it: In case this port is blocked, the assumption that VDR is running on the box should be >99%.

So in the next version I will adjust the check so it then uses the localhost address by default (with a messagebox explaining it).

I know, KDE4 is a hindering factor.

But if you want to try another way (I didn't yet), it may work following way:
- Install Qt 4.4
- Get the Phonon soucecode from KDE trunc (and only the phonon module, it is in kdesupport)
- Just compile the phonon module out of kdesupport
- Replace the phonon libs and the backend libs of Qt 4.4 with the kdesupport phonon libraries.

In KDE trunk, the xine backend has no more dependency on KDE anymore, so it just compiles with Qt 4.4 (for me it did)

What I don't know if there are changes in Phonon itself which would make KDE Phonon not work together with Qt 4.4
But based on the structure I've seen so far, it should not make any troubles.

This last step I will try at home soon. If it works I will post here the steps and also update the INSTALL instructions.

Hi Chris,

for myself not, but in the german forum I've seen some requests http://www.vdr-portal.de/board/thread.php?threadid=69824&threadview=0&hilight=vomp+wohnzimmer&hilightuser=0&page=10.
I'm just curious how it should react, when 2 persons are watching the same recording at the same time. One of the proposals was to have a second entry: resume from server.