vomp and vdr >1.7.3

[MartenR]

s it somehow possible for the client to test on which protcol-version the vompserver is using that it is connected to? In vompserver, I have a lot of "if VDRVERSNUM" 's which check on whether we are on vdr-1.7.3 + ; if it is (compiletime), but you don't want that on the client side; since the protocol has changed (slightly), the new client should be aware of which protocol version is used by vompserver.
Second best would be to check for vompserver-version (run-time), and assume when it is >0.3.0 that new protocol is used; this then would go wrong for people using  new vompserver on < vdr-1.7.2 .....

This is a normal problem, if vomp version number changes, that server and client must have the same version..
Since a new protocoll is necessary for the new vdr version, you should supply the new version of the vomp protocoll also for the old vdr version.
Thus you just say on vdr<1.7, that you have only pes recoridngs and so on. This shoulöd be possible since vdr>1.7.2 have also old pes recordings.
So you have a new vomp protocoll version for old vdr and new vdr and the user have just to use the same new version on client side and server side regardless of the vdr.
We have had this protocoll changes almost every release and we did it always like this.

Marten

[dingo35]

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).

P.S.: I record my progress in the original 7 point problem post, somewhere back in this thread...

[MartenR]

Well, other fields are fine, but I think you should code them after your TS stuff works to introduce not to much sources of error.

Comments to
7) No idea, may be they boardcast in a different way, since I do not know exactly your way you treat the PAt/PMT and figure out the pids,I can only guess: PAT/PMT with options your parser cannot handle, pes ids doubled. If you can I would suggest debugging with the Windows version. (Most mpeg decoder do not like debuggers, so please a MessageBox in the code you wanted to debug, place a breakpoint afterwards. Start the programm without debugger, wait for MessageBox, attach to process, press the button and debug for a while).

1) The current time is displayed, using player->getCurrentFrameNum() (using demuxer->getFrameNumFromPTS), so you have to track down, if all members are properly set, which are used in this function, maybe no pts set (no pts_map in demuxerts compared demuxervdr). For the fastforward, check if the getnextiframe command is properly handled on server and cleint side. Is navigation working with marks?

Marten

[muellerph]

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.

[dingo35]

I have a headless server, so I'm not using VDR settings and/or having easy access to change the vdr values.

The parameters mentioned are only setup once in VDR, they rarely change. Access is easy, even on a headless server, just bring your vdr process down and edit your setup.conf ...

But I'll leave it as it is, just wanted to propose an improvement. If it isn't percepted that way, it's useless...

[muellerph]

But I'll leave it as it is, just wanted to propose an improvement. If it isn't percepted that way, it's useless...

Hello Dingo,

sorry if I was giving you the impression of harsh wordings.

Such improvements are for sure welcome, I just wanted to add my 2 cents.

[dingo35]

Well, other fields are fine, but I think you should code them after your TS stuff works to introduce not to much sources of error.

Comments to
7) No idea, may be they boardcast in a different way, since I do not know exactly your way you treat the PAt/PMT and figure out the pids,I can only guess: PAT/PMT with options your parser cannot handle, pes ids doubled. If you can I would suggest debugging with the Windows version. (Most mpeg decoder do not like debuggers, so please a MessageBox in the code you wanted to debug, place a breakpoint afterwards. Start the programm without debugger, wait for MessageBox, attach to process, press the button and debug for a while).


1) The current time is displayed, using player->getCurrentFrameNum() (using demuxer->getFrameNumFromPTS), so you have to track down, if all members are properly set, which are used in this function, maybe no pts set (no pts_map in demuxerts compared demuxervdr). For the fastforward, check if the getnextiframe command is properly handled on server and cleint side. Is navigation working with marks?

Marten

7) is solved, problem was in scanForVideo; now only ts-radio does not work

1) navigation with marks is working ok, ffwd works fine but no update of picture, at normal play the time counter is not updated. I'll look into getnextiframe...

[dingo35]

I am trying to get the client to compile under windows, so that I can move to vdr-1.7.5 and not have to switch back all the time to vdr-1.7.0 because all my windows clients are incompatible; I have followed these instructions: http://forum.loggytronic.com/index.php?topic=327.0,

but this leads to missing header files (arpa/inet.h ,features.h, sys/cdefs.h, etc.) . I copied some of these files from unix /usr/include to windows VC9 include directory, but that really doesn't feel good...

What's the easiest way to build a windows vomp client, preferable without the result needing runtime libraries?

[MartenR]

(arpa/inet.h ,features.h, sys/cdefs.h, etc.)

This seems to be linux specific stuff.
Are you still using Yaris as basis? It includes patches, which include no adaption to windows.
Use cvs as basis, there everything should be ported, if it was cvs, tell me, so that I can try to port it.

Marten

[dingo35]

I'm still on Yaris version, will try the cvs version on windows first, to check if problem on my development environment or on Yaris version....

Thx for the pointer, Marten. Let me know when your vdr-1.7.5 version has arrived, I'll post my work so you can comment/improve on it....

[MartenR]

Code: [Select]

Let me know when your vdr-1.7.5 version has arrived,It is already there, but I have problems with the s2api driver and my kernel I had to resolve, so it is not really working in the moment, will take some time....

[MartenR]

So now its done. I can now switch between 1.6 and 1.7.
So if there are still problems I can join development next weekend, if you send me a patch based on cvs, or changed files.

Marten

[dingo35]

Hi Marten,

I am attaching my work in the form of two patches against current cvs (both server and client). The current issues are:

1) in ts-mode, no picture update when fast forward or fast rewind, no update of time-counter in the display

I have replicated a lot of code, and added modified versions of ScanForVideo and Stripaudio, but that doesn't seem to do the trick.

If this problem is solved, the code should be rescanned (I could do that) to make sure no unnecessary code is replicated, in search for the solution.
You will see this code marked by "HANS"  and "Do I need this?" kind of remarks.

Also I haven't bothered to look at the best solution for DemuxerTS and DemuxerVDR, where portions of code are now replicated that should better be shared. Perhaps DemuxerTS should be made a derivative of DemuxerVDR?


2) no AC3 yet;

3) subtitles or telext are not processed yet;

4) multipid audio works partly; the screen shows correct audio-languages, only somehow, after choosing the new language, the sound disappears. Playing around with setAudioChannel, setAudioStream and setAID didn't solve the trick.
I managed to get it working on the vomp-Yaris client, but not sure whether the modifications there are wanted in cvs code...

5) replaying of ts-radio recordings does not work

Also, in the server version part of the code is my "resume" patch; this patch makes vomp compatible with the VDR resume mechanism (see the thread on vdr-portal for exact description); it uses less code, and, sorry to say, better code, than cvs version, since it uses lot of VDR-routines. So please insert the _whole_ patch in cvs, so that my work does not disappear in the next version....

Also I am glad to say I managed to setup the windows compile environment, and both cvs and patched cvs compile fine; I have not tested extensively under windows, but it seems to be ok...

[MartenR]

1) no update of time-counter in the display
Solved, in processTS all parsepacktdetails have to be replaced with parsetsdetails.

More, to follow..

Marten

[dingo35]

Great Marten, I am currently looking at my next hurdle to go to vdr-1.7.5 : noad is not being able to process ts-streams. I am looking to integrating noad in vdr in the form of a plugin, so it can be much more efficient.

Only problem is that H264 streams are not being processed in vdr, but only in backends (xine or vdrpau), so even a new plugin will not be able to handle HD streams...