Volunteers for pre-alpha test of HDTV playback needed

[MartenR]

Hi,
maybe you have recognized, that vomp has now HDTV support in current cvs, this is mainly for windows in the moment. (Thanks to Carsten for testing).
I am searching for volunteers, who will test this HDTV feature on their machines using special vomp test builds I will provide the next days in this threads.
I need this to guarantee compatibility with a broad range of decoders and graphicscards.
So far recordings work and live TV may work.

A new vompserver is needed, which is incompatible with older versions.

Marten

[MartenR]

First Testversion, I will remove this version when a new testversion is posted here.
Please provide feedback!

Note: The cvs version of vompserver-plugin is needed!
At least vdr with built-in HDTV and TS recording needed. Only TS recording supported for HD playback.

Marten

[izeman]

hi marten

d'lded, tried out, but i stops at "connected, loading config", and using both cores @100%
could also be some security tool installed at my companies laptop.

i'll try some other pc and report back

regards izeman

[MartenR]

I think this because you have to update the server to cvs version.

Marten

[MartenR]

New version including test for dingo35.

Marten

[dingo35]

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

[MartenR]

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.

Actually, this setting makes sense. In windows it refers to the pixel aspect ratio. If someone connects a beamer or something else in anamorphic mode, the picture will look correctly in 16:9 mode. This with the side is the setting crop, you should change it to letter box.

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.

Hmm, You are the first who mentioned this and it is there since first relese. I will change it so it will ignore this setting.

Opening EPG window and pressing CTRL-R record results in a reproducable crash.

Since I have no live TV I cannot test this, logs around this crash would be good.

Also playing old vdr-hd-recordings goes wrong, the screen is not cleared properly, only the playing bar is displayed and that's it.

Actually the old HD recording were never supported by the plain vanilla vdr I think. Anyway they lack information in the recording format, so that I cannot identify them as HD so vomp tries to play them back as mpeg2 and this causes the lock up.
So they are just unsupported.

For the yaris version, it should be enough, if the protocoll changes in vdr.cc are proted back to the yaris client, then it should work with the new server. For the server side you can just genearte the diff from the cvs webpage and apply it to the yaris version then it should work.

Regarding the crash with CoreAvc, I need more information what happens(so may be a log or description what you see or what you have doone), you may also want to try  the decoder from the standalone filters from mediaplayer hc.




Thanks for testiing.

Marten

[dingo35]

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 !

[dingo35]

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


[dingo35]

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!

[MartenR]

@dingo35
Thanks for the logs, unfortunetely there is no hint for me in it.
Since I have no liveTV, I will look at the source code, if I get an idea what is going wrong.

Just a question was this bug also present in older vomp for windows versions. (I am asking since I have switched to a newer C++ version for the new builds).

Marten

[dingo35]

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

[rdoac]

@dingo35

Can you create a binary dongle for hardware mvp's from this code?

I can't get a dev env. to compile anymore..

[dingo35]

The rapidshare link points to the dongle binary. Object code = binary.

[rdoac]

Been trying to download it for the last half hour... They're busy and I'm not allowed to download it unless I pay up..

Still not working after two hours of continuous tries..

Can we upload this somewhere else?