I updated tvheadend to 4.0.9-1.1 last night on my 13.1 HTPC and found that my morning recording of BBC World News failed – ‘time missed error’.
Running service tvheadend status reveals that the dvb tuner card is not found:
# service tvheadend status
tvheadend.service - Tvheadend - a TV streaming server and DVR
Loaded: loaded (/usr/lib/systemd/system/tvheadend.service; enabled)
Active: active (running) since Mon 2016-04-11 09:08:05 PDT; 1min 4s ago
Process: 956 ExecStart=/usr/bin/tvheadend -f -p /var/run/tvheadend.pid $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1016 (tvheadend)
CGroup: /system.slice/tvheadend.service
└─1016 /usr/bin/tvheadend -f -p /var/run/tvheadend.pid -c /home/tvheadend/config -u hts -g video -6 --http_port 9981 --htsp_port 9982
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 18 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 57 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 3002 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 3003 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 0 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 1 [e=No such device or address]
Apr 11 09:09:00 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - failed to config dmx for pid 8187 [e=No such device or address]
Apr 11 09:09:01 susehtpc tvheadend[1016]: linuxdvb: Samsung S5H1409 QAM/8VSB Frontend : ATSC #0 - poll TIMEOUT
Apr 11 09:09:05 susehtpc tvheadend[1016]: mpegts: 207.028MHz in Antenna HDTV - scan no data, failed
Apr 11 09:09:05 susehtpc tvheadend[1016]: subscription: 0007: "scan" unsubscribing
The terminal output from the update is as follows:
(1/1) Installing: tvheadend-4.0.9-1.1 ................................................................................................[done]
Additional rpm output:
Updating /etc/sysconfig/tvheadend...
==> IMPORTANT: Post configuration tasks;
==> 1. Start the tvheadend service (to create home directory).
==> 2. Run tvheadend_super to set default username and password.
==> 3. Restart tvheadend service.
==>
==>
==> All further configuration is maintained through the web interface:
==>
==> http://localhost:9981/
==>
I am not sure I need to run tvheadend_super as this was an update, not a new install … I would rather not have to reconfigure everything! Tvheadend webadmin interface is fully available and all settings and configurations are correct per my original config.
Any ideas on why the dvb tuner is no longer available?
Hi
Interesting your the second person using tvheadend (see http://forums.opensuse.org/showthread.php?t=517058 openSUSE 13.2 and tvheadend 4.0.7) and having a driver issue. I’m the one who has pushed the last few updates, but I’m running tvheadend 4.0.9 on openSUSE Leap 42.1 without any issues.
For example;
systemctl -l status tvheadend.service
tvheadend.service - Tvheadend - a TV streaming server and DVR
Loaded: loaded (/usr/lib/systemd/system/tvheadend.service; enabled)
Active: active (running) since Sat 2016-04-09 10:10:13 CDT; 2 days ago
Process: 1197 ExecStart=/usr/bin/tvheadend -f -p /var/run/tvheadend.pid $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1409 (tvheadend)
CGroup: /system.slice/tvheadend.service
└─1409 /usr/bin/tvheadend -f -p /var/run/tvheadend.pid -c /home/tvheadend/config -u hts -g video -6 --http_port 9981 --htsp_port 9982
Apr 11 12:10:00 gekkota-tv tvheadend[1409]: mpegts: 479MHz in Local_FTA - tuning on Auvitek AU8522 QAM/8VSB Frontend : ATSC #0
Apr 11 12:10:00 gekkota-tv tvheadend[1409]: subscription: 00A6: "HTTP" subscribing on channel "WXVT-HD", weight: 100, adapter: "Auvitek AU8522 QAM/8VSB Frontend : ATSC #0", network: "Local_FTA", mux: "479MHz", service: "WXVT-HD", profile="matroska", hostname="::ffff:192.168.10.40", username="......", client="Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
....
What other updates have occurred on your system lately?
PS, the helper script I added was only for new installs or updating the admin use/password.
I don’t recall any other recent updates that would have affected tvheadend or the dvb tuner card, just some minor stuff. Recording worked fine through Saturday, the update was last night, error this morning … I just tried tuning into live broadcast, no signal found … which of course makes sense.
Perhaps it’s time for a system upgrade to 13.2, then on to Leap 42.1 … or perhaps rollback to previous tvheadend version? Is the rollback possible?
Hi
I see there was an update about a month ago, had the system been rebooted since then? If it hadn’t been restarted in a month or so, can you go into YaST Software management and rollback the kernel-firmware and see if that resolves the issue after another reboot.
Else if you read the other thread there is talk of the kernel being old, but I think it just maybe firmware.
Again, check via YaST Software management search for tvheadend and in the versions tab should be able to rollback to 4.0.8, else I can create a special build for you.
Thanks for the tip on using Yast version management. I’ll give a try.
Now, regarding your comment on kernel firmware – my system is rebooted almost daily using cron wol scheduling and a post-processing command following recording end time, or a cron scheduled shutdown script, so that should not be factor. The larger issue, though, may be related to two system patches, as follows:
$ zypper lp
Repository | Name | Version | Category | Status | Summary
---------------------+-------------------+---------+-------------+--------+----------------------------------------------------
openSUSE-13.1-Update | openSUSE-2014-515 | 1 | recommended | needed | kernel-firmware: Check for exact microcode filename
openSUSE-13.1-Update | openSUSE-2016-315 | 1 | recommended | needed | Linux kernel 3.12 version upgrade
I initially applied updates using the update notifier tool and deselected the patch, then installed all other updates. As the update notifier was an annoyance while watching video, I disabled the notifier and switched to manual zypper updates and put a lock on patch openSUSE-2014-515. This worked great until recently, where the lock does not function anymore, despite still being applied, meaning that any other patches cannot be installed because the patch command fails while trying to apply openSUSE-2014-515.
Noting that patch openSUSE-2016-315 involves kernel version upgrade, this is a problem!
I suppose it may be time to tackle that bug, listed above …
Hi
Yes, those two patches and some mismatch somewhere is probably the cause. Time to check the bug out or perhaps try a manual install of the downloaded packages or try a force on the install.
I tried a version rollback in Yast, but the only available version listed in Versions tab was the current one, reinstall the only option.
I looked in the bug report and patches posted on bugzilla and compared them to my system – the patches have been applied to the ucode/microcode update scripts, so I’m not sure why the update patches are failing …
I tried using online update and update notifier to deselect the older patch, but the install of the new kernel firmware patch fails as well, reporting that ucode-amd-20130714git-2.13.1.noarch is not installed. I try to install this package, a version check is done, stating that the package has a lower version than the one installed, and I can use --oldpackage to force installation, which then reports “nothing to do” …
Oh well, I suppose I could use a special build as you’ve offered, or pull the trigger and go for online upgrade to 13.2 to see if that fixes these issues … but that process looks a little painful and not so reliable.
If it’s not too much trouble, can you provide the build of the previous version?
Hi
Well that sucks I prefer fresh installs except with Tumbleweed which so far has behaved itself on my test system. Good luck with the fresh install
My tvheadend setup is the only thing running on that system (HP Pavilion 10 TS Notebook PC) it’s all it does, no desktop running, just use ssh for maintenance.
Well, seems like there’s a bit of luck on my side – after popping in the Leap NET install CD, I let it boot from hard drive just for fun, and discovered the 13.1 installation still intact, tvheadend included, and working!
The grub background and menu is different (has two entries for 13.1 now), along with the boot splash, but the system is up to date, minus Kodi and the hts pvr plugin …
The older microcode check patch is no longer listed, just the newer kernel firmware version update, but that still fails on the ‘missing’ microcode noarch package …
Well, I’m not complaining, suppose I will hold off on the clean install until EOS for 13.1 …
Yet, now I am experiencing a problem with my Kodi packages. Both zypper and Yast software management reported them installed, but the executable in /usr/bin/ wasn’t found, so I uninstalled kodi and the pvr.hts addon, then reinstalled. Now it complains that it can’t find libGLEW.so.1.9 on startup …
Much thanks. I hadn’t found the package using zypper or in Yast software management (I suspect this is due to some repository oddities due to the failed upgrade).
One click install failed on software.opensuse.org – a look through /var/log/YaST2/y2log revealed a problem:
rpmdb2solv: inconsistent rpm database, key 1839 not found
# rpm --rebuilddb
fixed this, then I was able to install the 64 bit rpm package. Now everything is working again.
I prefer fresh installs except with Tumbleweed which so far has behaved itself on my test system. Good luck with the fresh install
My tvheadend setup is the only thing running on that system (HP Pavilion 10 TS Notebook PC) it’s all it does, no desktop running, just use ssh for maintenance.
On a side note, I recently attempted a clean install of Tumbleweed on my HP Elitebook 8540w using a new OCZ SSD, but it failed, so I decided to give Debian a try, which has worked out well (currently running Testing - Stretch due to a kernel issue with Stable - Jessie, an X crash bug affecting, in my case, xsane and a brother printer mfc-j4420dw).
Still hoping to roll with Tumbleweed someday though …
