-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error with CRC in tables (ie. PAT table) #18
Comments
Hi, the warning message "WARNING Detected dvbloopback" got my interest. I had a quick look into the source code and found this interesting comment: https://git.linuxtv.org/v4l-utils.git/tree/lib/libdvbv5/dvb-dev-local.c#n453 So it seems that the developers are aware that dvbloopback is (was?!) broken at some point in time ("in recent kernels"). Maybe there are some fundamental issues with dvbloopback, or dvbloopback is no longer broken but a check for dvbloopback stops it from being used as intended. Regards, |
Hi Florian, There a couple of references to dvbloopback. I believe the FE_GET_FRONTEND issue they mention should be fixed now. Let me play around with this libdvbv5 and see if things still work without the special dvbloopback conditions/clauses. |
Just a quick comment: I've removed the dvbloopback specifics out of libdvbv5 and nothing changes. 'dvbv5-scan' gives the same results, including CRC error. Even by bypassing the CRC check, the scan does not report any proper channels.conf, while doing this on the physical adapter works perfectly. |
I believe this is a descrambler issue, but could also be dvbloopback.
CRC of certain tables is failing using descrambler/dvbloopback, doing a channel-scan using dvbv5-scan.
In the example it below, it fails with 'table ID 0x00, program ID 0x00', but it fails also with other tables.
See response of virtual adapter:
See response of physical adapter:
< break >
The text was updated successfully, but these errors were encountered: