Skip to content
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

DVB fixes (slow hardware, VDR channels.conf) #6835

Merged
merged 2 commits into from
Sep 1, 2019

Conversation

olifre
Copy link
Member

@olifre olifre commented Jul 31, 2019

Discussion in #6372 has highlighted two issues which are fixed in this commit series:

  • VDR channels.conf is rather flexible about units for the frequency (it accepts Hz, kHz and MHz). We now do as VDR does and multiply the value provided in the config file by 1000 until 1000000 is reached. This fixes compatibility especially with more recent channels.conf files.
  • DVB-T2 hardware in some cases seems to be too slow to actually deliver data within 2.5 seconds(!) after tuning. Increase the timeout to 10 seconds.

I agree that my changes can be relicensed to LGPL 2.1 or later.

Thanks to @berndbb both for finding the issues and for testing my fixes on his HW!

olifre added 2 commits July 29, 2019 22:42
While they accept the frequency field with MHz for DVB-S,
for DVB-C and DVB-T, it may be in Hz, kHz or MHz.
The official rule is to multiply whatever is in the channels.conf
by 1000 until a value > 1000000 is reached to get correct units for tuning.
It seems some DVB-T2 cards take longer to push out data.
Copy link
Member

@jeeb jeeb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@jeeb
Copy link
Member

jeeb commented Sep 1, 2019

2 seconds could be a bit long, but we anyways at the previous maximum would have waited until 2.5 seconds (500ms * 5). This now gets bumped to 10 seconds (2000ms * 5).

@jeeb jeeb merged commit c8424a3 into mpv-player:master Sep 1, 2019
@olifre
Copy link
Member Author

olifre commented Sep 1, 2019

2 seconds could be a bit long, but we anyways at the previous maximum would have waited until 2.5 seconds (500ms * 5). This now gets bumped to 10 seconds (2000ms * 5).

Indeed. I was really astonished that the DVB-T hardware mentioned in the linked thread was too slow and did not deliver any data in 2.5 seconds, which I already considered to be rather long - but bumping that has helped the user, who could not tune at all (and also my DVB-S card takes a second or so until first data arrives). Thanks for merging!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants