Some models not working

[bubbaprog]

Thanks for your work on this project — it's a lifesaver. My two HDPVR2s that have the micro-USB connector are working great. My three that use full-size USB are not, and all of them fail with the following output:

2021-07-22T17:07:54.745100 CRIT <main> Logger.cpp:83 (setLogLevelFilter) Changing loglevel to NOTC 2021-07-22T17:07:54.745249 CRIT <main> hauppauge2.cpp:347 (main) Starting up 2021-07-22T17:07:54.759594 CRIT <main> hauppauge2.cpp:360 (main) Initializing [Bus: 3, Port: 3] E504-00-00ACD92B 2021-07-22T17:08:04.251564 WARN <HAPI-cmd> Hapi.cpp:383 (cmdThreadFunc) pMsgWaitingRsp=0x5622eb167aa0 waiting for 3366ms(limit=5000) 2021-07-22T17:08:05.383079 WARN <HAPI-cmd> Hapi.cpp:383 (cmdThreadFunc) pMsgWaitingRsp=0x5622eb167aa0 waiting for 4498ms(limit=5000) 2021-07-22T17:08:06.114168 ERRR <main> Hapi.cpp:3187 (HAPI_Start) HWAPI_MESSAGE_START fail!!! sem err:3, rspCode:0x01000000 2021-07-22T17:08:06.114341 ERRR <main> HauppaugeDev.cpp:686 (StartEncoding) Encoder start capture failed.

The models are 157221 and 157220. They work on other operating systems. The differences I've found are:

The full-size USB models report a Device Status in lsusb of 0x0003, Self-Powered, Remote Wakeup Enabled. The micro-USB models report 0x0001, Self-Powered. The idProduct is 0xe504 as opposed to 0xe505 on the newer, working ones.

Also, and this may be the biggest clue of all (?) the older units don't seem to obey the permissions rules in the udev, meaning the app only sees them if i run it as sudo.

As reported by the script, we have

[Bus: 3 Port: 2] 2040:0xe514 E514-00-00AB340A HD PVR 2 model 1512 w/SPDIF, Alt bling (Siena2-02) (a 220) Number of possible configurations: 1 Device Class: 0 VendorID: 8256 ProductID: 58644

for both models.

Debug log attached. hauppauge2-E514-00-00AAAEA7.144744.log

[bubbaprog]

After (exhaustive) work on this, I've discounted the udev stuff (that gets resolved with a reboot), and it's only two of them that have these results: a 2040:0xe504 and a 2040:0xe514. Both record fine if fed DD 2.0, but produce the above results when fed DD 5.1. Both operate properly when using HDPVRCapture or other desktop apps.

[jpoet]

Unfortunately, where it is failing for you appears to be in the code provided by Hauppauge. It has been a long time since I dug into it, and it is rather ugly, so takes some study.

Can you give the "transcode" branch a try? I don't know why it would necessarily work, but that is the latest code. At the moment, that branch /always/ transcodes and I want to make it where it only transcodes if the codec is actually different than is what is provided -- I just have not gotten around to it. That is why it has not been merged into master yet. That being said, it does handle audio better than the master branch in some ways and maybe it will be helpful in your situation.

[bubbaprog]

I tried the Transcode branch but the additional patches failed. If there is some modification needed beyond checking the branch out and applying the patches using the same pattern as the other seven let me know. I appreciate all the work you & other contributors have made to this project and if I were versed in this language I'd be right in it with you.

this is the patch command I ran:

cd ~/src/Hauppauge2/HauppaugeUSB/Hauppauge
for fl in 01-NewLine.patch \
          02-string.patch \
          03-EnableRegisteredParameters.patch \
          04-SplitLoggingLevels.patch \
          05-FirmwareLocation.patch \
          06-AVOutputCallback.patch \
          07-ThreadName.patch \
      08-AddSetAudio.patch \
      09-AddSemaphores.patch
do
    patch -p1 < ~/src/Hauppauge2/HauppaugeUSB/Patches/"${fl}"
done

[davepearson1628]

Did you ever manage to get this problem resolved, if so, how? I have aquired a 157220 model and am encounteringthe same issue.

[jpoet]

Were you able to figure out the udev issue? The provides udev rules assume ATTRS{idVendor}=="2040". If you use udevadm to examine the problematic device, does it show the same vendor? For example, something like: udevadm info -a -p /class/video4linux/video1

As far as getting the different models working, I am sorry but I won't be of much help any time soon. I don't even have access to my old Colossus2 at the moment.

[bubbaprog]

Yes — I built an entirely separate system dedicated to this and actually have five of them working extremely solidly simultaneously and with separate composite video inputs for capturing VBI data. I suspect the udev issues were related to some other things on that machine, or perhaps its USB chips.

The motherboard on that system ended up dying and I replaced it with another one, which also works as expected. There are tiny differences in models—I think the Kernellabs guys ended up identifying more than 20 different versions of the HDPVR2—and some of them simply aren't going to work with this script, but what you've done here is more than enough. I think I've got ten of these things now, and five of them work, and that's .. sufficient for what I need to do, right now at least.

[davepearson1628]

I tried the transcode branch and that didn't resolve my problem, I've also tried the new master branch which you (jpoet) updated a couple of days ago. I cannot seem to get any audio with my GE Plus, I can get a perfect picture, but no sound - I've tried:

SPDIF - AAC & AC3 HDMI - AAC & AC3

none of the options seem to work.

I do know that it works with Hauppauge's own capture utility on Windows, so I don't have faulty hardware.

It's interesting that the new version seems to support AC3 on devices without SPDIF, I'm wondering if I should try and get hold of one of those?