Messages

To all who stumble on this in the archives: the HD vomp for windows alpha version works with CoreAVC 2.0

I dont recall it was present in older windows version, I will check but need to downgrade then (cannot do that right now, TV clients are active now :-) ).

For people who also want to test Martens HD version for vomp for windows, but dont want to say goodbye to Yaris functionality, I have made some new sources.

vompserver: the source code for vompserver, this is the Yaris version, to which I have added the cvs-changes of the last 6 months; also I added my patch for PIN-plugin awareness, when USE_PINPLUGIN is not set this code is ignored.
client: the source code for the dongle, this is the Yaris version, to which I have added the cvs-changes of the last 6 months, and also the hdtv2.patch of Marten.
vomp-dongle: the dongle object code; too large for this board, so here: http://rapidshare.com/files/355178923/vomp-dongle-0.3.1-2-Yaris-HD.gz

Enjoy!

Pressing CTRL-R = record in epg menu results in windows error report with dialog box that ask whether to send the report to Microsoft or not. The application keeps running until you select "not send", then it ends gracefully (no remaining vomp-process).

The signature of the error is:

Code Select Expand

AppName: vomp on windows.exe AppVer: 0.0.0.0 ModName: msvcr90.dll
ModVer: 9.0.30729.1 Offset: 000518a8

The file that would be send to Microsoft contains:

Code Select Expand

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="Vomp on Windows.exe" FILTER="GRABMI_FILTER_PRIVACY">
   <MATCHING_FILE NAME="Vomp on Windows.exe" SIZE="962560" CHECKSUM="0x22F8E96F" MODULE_TYPE="WIN32" PE_CHECKSUM="0xED0F5" LINKER_VERSION="0x0" LINK_DATE="02/22/2010 15:18:24" UPTO_LINK_DATE="02/22/2010 15:18:24" />
</EXE>
<EXE NAME="MSVCR90.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
   <MATCHING_FILE NAME="msvcr90.dll" SIZE="655872" CHECKSUM="0xA8551049" BIN_FILE_VERSION="9.0.30729.1" BIN_PRODUCT_VERSION="9.0.30729.1" PRODUCT_VERSION="9.00.30729.1" FILE_DESCRIPTION="Microsoft® C Runtime Library" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Visual Studio® 2008" FILE_VERSION="9.00.30729.1" ORIGINAL_FILENAME="MSVCR90.DLL" INTERNAL_NAME="MSVCR90.DLL" LEGAL_COPYRIGHT="© Microsoft Corporation.  All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA6621" LINKER_VERSION="0x90000" UPTO_BIN_FILE_VERSION="9.0.30729.1" UPTO_BIN_PRODUCT_VERSION="9.0.30729.1" LINK_DATE="07/29/2008 10:53:57" UPTO_LINK_DATE="07/29/2008 10:53:57" VER_LANGUAGE="Engels (Verenigde Staten) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
   <MATCHING_FILE NAME="kernel32.dll" SIZE="1030656" CHECKSUM="0x1B46B288" BIN_FILE_VERSION="5.1.2600.5781" BIN_PRODUCT_VERSION="5.1.2600.5781" PRODUCT_VERSION="5.1.2600.5781" FILE_DESCRIPTION="DLL-bestand voor Windows NT BASE API-client" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Besturingssysteem Microsoft® Windows®" FILE_VERSION="5.1.2600.5781 (xpsp_sp3_gdr.090321-1317)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle rechten voorbehouden." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x101480" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5781" UPTO_BIN_PRODUCT_VERSION="5.1.2600.5781" LINK_DATE="03/21/2009 14:09:59" UPTO_LINK_DATE="03/21/2009 14:09:59" VER_LANGUAGE="Nederlands (Nederland) [0x413]" />
</EXE>
</DATABASE>


Log:

Code Select Expand

14:08:06.000437 [debug]  VDR - Have added a channel to list. 4751 1 Das Erste HD
14:08:06.000437 [debug]  VDR - Have added a channel to list. 4752 1 ZDF HD
14:08:06.000453 [debug]  VDR - RR sleep - opcode 10
14:08:06.000484 [debug]  VDR - Rxd a response packet, requestID=83, len=581
14:08:06.000484 [debug]  VDR - RR unsleep
14:08:06.000484 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000484 [debug]  VDR - RR sleep - opcode 10
14:08:06.000531 [debug]  VDR - Rxd a response packet, requestID=84, len=4215
14:08:06.000531 [debug]  VDR - RR unsleep
14:08:06.000531 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000531 [debug]  VDR - RR sleep - opcode 10
14:08:06.000562 [debug]  VDR - Rxd a response packet, requestID=85, len=2810
14:08:06.000562 [debug]  VDR - RR unsleep
14:08:06.000562 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000562 [debug]  VDR - RR sleep - opcode 10
14:08:06.000593 [debug]  VDR - Rxd a response packet, requestID=86, len=1418
14:08:06.000593 [debug]  VDR - RR unsleep
14:08:06.000593 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000593 [debug]  VDR - RR sleep - opcode 10
14:08:06.000640 [debug]  VDR - Rxd a response packet, requestID=87, len=621
14:08:06.000640 [debug]  VDR - RR unsleep
14:08:06.000640 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000640 [debug]  VDR - RR sleep - opcode 10
14:08:06.000687 [debug]  VDR - Rxd a response packet, requestID=88, len=1265
14:08:06.000687 [debug]  VDR - RR unsleep
14:08:06.000687 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000687 [debug]  VDR - RR sleep - opcode 10
14:08:06.000703 [debug]  VDR - Rxd a response packet, requestID=89, len=171
14:08:06.000703 [debug]  VDR - RR unsleep
14:08:06.000703 [debug]  VDR - Success got to end of getChannelSchedule
14:08:06.000703 [debug]  Boxx - Construct, now 34
14:08:07.000312 [debug]  VDR - RR sleep - opcode 10
14:08:07.000312 [debug]  VDR - Rxd a response packet, requestID=90, len=2539
14:08:07.000312 [debug]  VDR - RR unsleep
14:08:07.000312 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000312 [debug]  VDR - RR sleep - opcode 10
14:08:07.000343 [debug]  VDR - Rxd a response packet, requestID=91, len=37
14:08:07.000343 [debug]  VDR - RR unsleep
14:08:07.000343 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000343 [debug]  VDR - RR sleep - opcode 10
14:08:07.000390 [debug]  VDR - Rxd a response packet, requestID=92, len=32
14:08:07.000390 [debug]  VDR - RR unsleep
14:08:07.000390 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000390 [debug]  VDR - RR sleep - opcode 10
14:08:07.000406 [debug]  VDR - Rxd a response packet, requestID=93, len=581
14:08:07.000406 [debug]  VDR - RR unsleep
14:08:07.000406 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000406 [debug]  VDR - RR sleep - opcode 10
14:08:07.000453 [debug]  VDR - Rxd a response packet, requestID=94, len=2810
14:08:07.000453 [debug]  VDR - RR unsleep
14:08:07.000453 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000453 [debug]  VDR - RR sleep - opcode 10
14:08:07.000500 [debug]  VDR - Rxd a response packet, requestID=95, len=1460
14:08:07.000500 [debug]  VDR - RR unsleep
14:08:07.000500 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000500 [debug]  VDR - RR sleep - opcode 10
14:08:07.000546 [debug]  VDR - Rxd a response packet, requestID=96, len=523
14:08:07.000546 [debug]  VDR - RR unsleep
14:08:07.000546 [debug]  VDR - Success got to end of getChannelSchedule
14:08:07.000609 [debug]  Timers - Starting set timer 1
14:08:07.000609 [debug]  Timers - Timer set for 015B93D0 ref 1
14:08:07.000609 [debug]  Boxx - Destruct, now 33
14:08:07.000609 [debug]  BoxStack - add called
14:08:07.000609 [debug]  BoxStack - Locked for add
14:08:07.000609 [debug]  BoxStack - Unlocked for add
14:08:07.000609 [debug]  BoxStack - Update called
14:08:07.000609 [debug]  BoxStack - Locked for update
14:08:07.000609 [debug]  BoxStack - Unlocked for update
14:08:10.000093 [debug]  VDR - Sending KA packet
14:08:10.000109 [debug]  VDR - Rxd correct KA reply
14:08:16.000125 [debug]  VDR - Sending KA packet
14:08:16.000203 [debug]  VDR - Rxd correct KA reply


I found newest client: http://forum.loggytronic.com/index.php?action=dlattach;topic=507.0;attach=188.

Shall I generate patch to update Yaris version or will you do that?

I hadnt noticed sourceforge CVS browse access, I will surely apply the changes of last weeks to Yaris so larger audience can join.

Good to know you have no live stream access, I will gather logs where possible !

Marten, I have done some limited testing. Here are my first findings.

First try didnt work, then set my h264filter to my installed CoreAVC plugin and beautiful picture + sound. I had some crashes of the windows program, server survived, but I couldnt reproduce them.
When it all worked, I noticed the sides fell off this 16:9 broadcast. I went to my settings, they were on 4:3, and changed that to 16:9 . Now I dont lose side of the picture, but it all gets stretched out in vertical position: the 16:9 picture is put in a 4:3 window.
It seems silly to me that a windows application obeys this setting (I suggest to ignore it), but if it does it should do it right.

Then somehow the application crashed, and I couldnt get it working again. Then I remembered I had changed poweron value to OFF, and yes, unbelievable, but the windows application actually obeys this setting and shuts itself down when starting up :-) . Here also: ignore this setting.

After a crash I had to restart the machine, so vompclient and/or CoreAvc can crash nastily; no logs since not reproducable :-( .

Opening EPG window and pressing CTRL-R record results in a reproducable crash. Also playing old vdr-hd-recordings goes wrong, the screen is not cleared properly, only the playing bar is displayed and that's it.

In order to do more structural testing, I would implement new vompserver on my production system, but then I would loose Yaris patching functionality, and that is unwanted on my production system.
Is it somehow possible to:
1)  produce the cvs-patches and take them to Yaris-repository so we get an updated server there?
2)  same for client code needed to use new server version? I am talking about dongle code for mediamvp box, not the windows version.

That way I could integrate alpha windows in my production environment, which would improve testing / error finding...

Ok, I will test your HD version asap (hoping this issue will be fixed in that version :-)  ).

Thanks Marten!

Hi Marten,

Glad to report that your patch fixed problem 2) beautifully!! First tests show jumping + updating of seconds counter ok :-)

Problem 2) still exists, I will try to produce more output, it is hard to reproduce. I suspect it has to do with timings, I also have posted other patches that no-one seem to need, I have a videoserver with 4 DVB-cards, 3 client mvps and 4 windows-mvp,s so sometimes that generates a lot of load....

My Windows-compiler broke, could you perhaps post a windows version with your patch in it?

Thanks! Dingo.

@hondans, could you please bring out a new dongle with the patch from Marten (see http://forum.loggytronic.com/index.php?topic=506.0) for transponders that send multiple pesframes per tsframe

I have tested it and it works fine!

Thanks!

Thanks Marten for your quick solution !!!!!

No, that must be different problem: I have "my" problem _never_ with PES recordings, and _only_ with TS recordings from this particular transponder. It also happens repeatedly in such a recording.

I have a few minutes of sample stream here http://rapidshare.com/files/346156998/wrongts.tgz

You have mail...

I have come across two different bugs in vompserver:
1) sometimes, when I start a recording, the current time/total time is not filled in correctly, but displays  --/-- .
When it goes wrong, the client sends command 7 directly after selecting the recording:

Code Select Expand

09:47:21.133495 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00001.ts
09:47:21.133561 [debug]  RecPlayer - File 1 found, totalLength now 130461284, numFrames = 6599
09:47:21.133599 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00002.ts
09:47:21.133686 [debug]  RRProc - written totalLength
09:47:21.133725 [debug]  RRProc - threadMethod waiting
09:47:21.134574 [debug]  Client - Received chan=1, ser=9808, op=7, edl=12
09:47:21.134611 [debug]  RRProc - recvReq set req and signalled
09:47:21.134632 [debug]  Client - Waiting
09:47:21.134657 [debug]  RRProc - thread woken with req, queue size: 1
09:47:21.134677 [debug]  RRProc - thread while
09:47:21.134702 [debug]  RRProc - received command 7
09:47:21.134723 [debug]  RRProc - getblock pos = 0 length = 10000


And when it goes right, it first does command 16:

Code Select Expand

09:47:21.453342 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00001.ts
09:47:21.453409 [debug]  RecPlayer - File 1 found, totalLength now 130461284, numFrames = 6599
09:47:21.453448 [debug]  RecPlayer - FILENAME: /media/video0/NED2/2010-02-03.14.57.2-0.rec/00002.ts
09:47:21.453532 [debug]  RRProc - written totalLength
09:47:21.453572 [debug]  RRProc - threadMethod waiting
09:47:21.460124 [debug]  Client - Received chan=1, ser=9814, op=16, edl=4
09:47:21.460168 [debug]  RRProc - recvReq set req and signalled
09:47:21.460189 [debug]  Client - Waiting
09:47:21.460216 [debug]  RRProc - thread woken with req, queue size: 1
09:47:21.460237 [debug]  RRProc - thread while
09:47:21.460261 [debug]  RRProc - received command 16
09:47:21.460300 [debug]  RRProc - Wrote posFromFrameNum reply to client


2) ONLY on recordings from transponder 12515H on S19.2E (Ned1, Ned2, Ned3), there are positioning problems.
-When you are looking to a recording, the "seconds" field updates much to slow (so it takes 1,5 seconds to show 0.01)
-When fastforward or rewind, the point from which is jump is "back in time". Here is the log when I jump forward 10 seconds:

Code Select Expand

10:00:35.091598 [debug]  RRProc - received command 7
10:00:35.091621 [debug]  RRProc - getblock pos = 17550000 length = 100000
10:00:35.091928 [debug]  RRProc - written 100000
10:00:35.174426 [debug]  RRProc - Finished getblock, have sent 100012
10:00:35.174549 [debug]  RRProc - threadMethod waiting
10:00:35.256136 [debug]  Client - Received chan=1, ser=10804, op=16, edl=4
10:00:35.256265 [debug]  RRProc - recvReq set req and signalled
10:00:35.256289 [debug]  Client - Waiting
10:00:35.256321 [debug]  RRProc - thread woken with req, queue size: 1
10:00:35.256344 [debug]  RRProc - thread while
10:00:35.256371 [debug]  RRProc - received command 16
10:00:35.256431 [debug]  RRProc - Wrote posFromFrameNum reply to client: position=10600756 framenumber=485
10:00:35.256464 [debug]  RRProc - threadMethod waiting
10:00:35.257444 [debug]  Client - Received chan=1, ser=10805, op=7, edl=12
10:00:35.257478 [debug]  RRProc - recvReq set req and signalled
10:00:35.257498 [debug]  Client - Waiting
10:00:35.257522 [debug]  RRProc - thread woken with req, queue size: 1
10:00:35.257542 [debug]  RRProc - thread while
10:00:35.257562 [debug]  RRProc - received command 7
10:00:35.257631 [debug]  RRProc - getblock pos = 10600756 length = 100000


These particular stream are OK when live viewing, and also in VDR itself. I noticed that the "resume" function works correctly, so it has to do with the way vompclientrrproc.c derives the framenumber from the stream through ntohl. I cannot detect where this req->data is filled, though ...

A temporary fix is in line 1222 of vompclientrrproc.c:

Code Select Expand

  //ULONG frameNumber = ntohl(*(ULONG*)req->data); //FIXME DINGO
  frameNumber = x.recplayer->frameNumberFromPosition(x.recplayer->getLastPosition());

..but this isnt really ok since the last position is only a rough estimate, and is not updated frequently.

Can someone (Marten?) point me into the right direction: which fields in the ts-stream are causing this problem, and/or where is this req->data filled, and/or how to solve this in vomp (if VDR is not the right place to solve this) ?

Thanks Dingo.

...sorry, still waiting for noad for ts.... until then on 1.7.0 .

EDIT: switched to vdr-1.7.11, no special adaptions needed, it works right out of the box...