Windows - Humour Me... New Windows PVR (Perhaps)

  Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
Prof Yaffle Offline
Donor
Posts: 1,092
Joined: Mar 2011
Reputation: 23
Location: UK - in the middlish (mostly).
Post: #16
Build complete with a couple of errors, but they don't look disastrous - just that the new module effectively matches the current one for a couple of components, e.g.

Code:
zr364xx.ko:
Running module version sanity check.
Error! Module version 0.7.4 for zr364xx.ko
is not newer than what is already found in kernel 3.0.0-23-generic (0.7.4).
You may override by specifying --force.

zr36067.ko:
Running module version sanity check.
Error! Module version 0.10.1 for zr36067.ko
is not newer than what is already found in kernel 3.0.0-23-generic (0.10.1).
You may override by specifying --force.

... so I've left those all well alone since it doesn't look like it needs forcing.

That aside, I rebooted and was greeted by a familiar screen,plus I can see the Q-Box in the tvheadend web interface, so it's promising so far. Let's see.
find quote
Prof Yaffle Offline
Donor
Posts: 1,092
Joined: Mar 2011
Reputation: 23
Location: UK - in the middlish (mostly).
Post: #17
Went for a kernel update last night.

Good news - the dkms additions above meant that the kernel installed and the compute immediately went into a recompile for the TBS drivers... reboot after that, and tvheadend could happily see the TBS box and satellite channels. Success!

Bad news - my DVB-T tuner, which has survived every kernel replacement because it's supported out-of-the-box, completely failed to work after the new kernel was installed. All error messages seemed to point to dkms-related shared libraries, so I've clearly got some more sleuthing to do there.

Hey-ho. This is why we like Linux, right? ;-)
find quote
Prof Yaffle Offline
Donor
Posts: 1,092
Joined: Mar 2011
Reputation: 23
Location: UK - in the middlish (mostly).
Post: #18
Right. Diary time so I keep on top of this... I'm getting two lots of errors in syslog:

Code:
dvb_usb: disagrees about version of symbol dvb_dmxdev_init

and

Code:
dvb_usb: Unknown symbol dvb_dmxdev_init (err -22)

From hunting around, the first effectively means that the module is intended for a different kernel version. The second means that the module has a dependency on a symbol (the same one) that should be in the kernel, but isn't - the kernel was compiled with it missing and/or it's no use because of that version issue. Both mean a reconfigure-and-recompile of the kernel.

Now, my DVB-T card is supported in all even vaguely-recent kernels, but all this suggests that I still need to recompile it specifically for this one. My suspicion is that dkms is recompiling that bit of the "normal" kernel build (v4l), but leaving out the support for this card, instead relying on the currently-compiled version... which it doesn't like.

Soooo... I can think of three options:

1. Break the yavdr package and manually insert the driver code into the right place (/usr/src/linux-media-tbs-0~20111123.111118.1~oneiric) - but that will get promptly eaten at the next ppa update (presumably triggered by TBS updating their drivers, but not necessarily looking at the dates - TBS' current version is 120814 - so 14/Aug - versus the ppa date of 23/Nov last year - so such an update may never happen or be intermittent). Sounds like a bad idea.

2. Create my own dkms directory for these drivers (installed into /usr/src) so that it compiles alongside the TBS files. That'd work, but I'm still dependent on the yavdr versions.

3. Abandon the yavdr dkms package now I can see what it's doing, and move the full TBS v4l tree (which includes all the right drivers) into /usr/src along with a hacked version of the dkms.conf from the yavdr ppa. I can then uninstall the yavdr TBS package.

All options would give me the DiBcom7000 drivers *and* the TBS drivers - but the third option allows me to update those drivers when TBS release a new version (indeed, I can build those drivers in now since I'd control that dkms package). So that's the route I'm going to investigate...

Update as I get anywhere.
find quote
Prof Yaffle Offline
Donor
Posts: 1,092
Joined: Mar 2011
Reputation: 23
Location: UK - in the middlish (mostly).
Post: #19
Make that last line IF I get anywhere...
find quote
speed32219 Offline
Fan
Posts: 410
Joined: Feb 2007
Reputation: 0
Post: #20
(2012-08-18 19:58)Prof Yaffle Wrote:  Make that last line IF I get anywhere...

I feel your pain with all the pvr stuff, and only working with certain tuners but with limited options. (recordings, epg, etc.)
I settled on Mythtv-backend (.25+fixes) and myth-frontends on my stb's. I just use Launcher to launch it from within XBMC using a fluxbox session and it works great. My backend has been running over 30 days without error and the frontends are on for days at a time. I do get an error every now and then (not often) and I have full DVR functionality recording multiple shows at the same time (Using Ceton Tuner). Heck, I even had PIP working with two ballgames on but @ 100% cpu utilization but it worked and I could jump from session to session with sound. The remote on both apps is fully functional while the video displayed on TV using Myth is better than xbmc with SD interlaced content. I have the best of both worlds right now, but I do use the Libcmyth addon every now and then, I do love the integration within XBMC, just isn't fully developed yet, just need more time
(This post was last modified: 2012-08-20 04:05 by speed32219.)
find quote
Post Reply