Swifty
Fan Posts: 482 Joined: Nov 2008 Reputation: 1 |
2012-07-28 15:42
Post: #11
Check the yavdr ppa for dvb related dkms packages for your distro, they have one that includes tbs support.
|
| find quote |
nobleach
Junior Member Posts: 38 Joined: Nov 2008 Reputation: 0 |
2012-08-01 18:03
Post: #12
(2012-07-27 10:43)Prof Yaffle Wrote: dkms? Never knew about it... oooh, ooh, you have me intrigued now. I'm really not getting on with FTR and/or Windows (problems tuning to channels, tuners dropping, endless issues with Windows share permissions and domain logins, not enough grunt to effectively stream even SD channels off the server - plus I miss the simplicity of tvheadend's EPG compared to FTR). The biggest gripe I had with 4TR/XBMC-PVR was that the channels would show up twice, and most of them would refuse to tune. I downloaded the latest 4TR/Argus and gave it a shot. I wiped out the DB and started fresh. I scanned for channels, made sure to link them all up properly. I went downstairs and enabled the 4TR client (which I, like you had to hack the crap out of Pulse8's version of OpenElec to get it working) It pulled in the list of channels, everything was wrong! So I jumped into XBMC's settings and told it not to cache the EPG, and use channel order from the backend. Low and behold, that worked well. Channels still refuse to tune from time to time, but tuning another channel then switching back usually works. I get a LOT of buffering with HD channels... far more than I got with TVHeadend... but I'm also on wireless. Overall it's working not so badly. |
| find quote |
Prof Yaffle
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-05 13:03
Post: #13
I threw in the towel on FTR yesterday when I realised that it was constantly eating 60-70% CPU between a couple of permanent services/processes... the impact of that was too much, even copying files was enough to virtually seize up the system. Nothing personal, it's a fine backend and they all have their quirks - I think it just needs a bigger box than my first-generation ION Revo 3600 - plus Win7 isn't the lightest of host OSes, even with lots of RAM and an SSD.
Rebuilt under XBMCBuntu and Pulse8's XBMC/tvheadend, and the whole system was back up and running in a couple of hours. Now running with enough CPU to spare so that I can actually use XBMC at the same time! Now, time to look at dkms without breaking anything... |
| find quote |
KRA77
Senior Member Posts: 192 Joined: Jul 2010 Reputation: 0 |
2012-08-05 14:21
Post: #14
I had the same problem with FTR, eating all my CPU, then I notice it was all my 3 dvb cards grabbing EPG. So I tweaked the grabbing options a little and problem solved.
|
| find quote |
Prof Yaffle
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-05 18:46
Post: #15
@KRA77 - yes, I suspected the same, but I think I've just become more comfortable with Linux than Windows despite sitting in front of the latter all day, every day at work. So tvheadend it is for me for the moment, at least.
Anyway... TBS drivers... I have no real idea what I'm doing here, but you don't learn by staying safe - thanks for the pointers, guys, I've taken the plunge and done... well, something :-) After a good bit of Googling and reading, I installed the yaVDR repository: Code: sudo apt-add-repository ppa:yavdr/mainUpdated package list and upgraded anything that comes with this repository: Code: sudo apt-get updateThis updated dkms, libva, nvidia-current, lirc and a few others. As an aside, the nvidia-current upgrade seems to have installed updated NVidia drivers (295.20 vs the current Oneiric 280.13) in dkms "format", so I suspect that these will also survive a kernel update in future. If I find myself at a login prompt instead of XBMC at some point, I'll know that last statement was wrong... Anyway, install the TBS driver package: Code: sudo apt-get install linux-media-tbs-dkms... this also installed a couple of dependencies, and is building the kernel modules as I type: Code: DKMS: add completed.So let's see what happens. I'll reboot first and see if anything still works! It's all a learning process for me, so (assuming that the system hasn't now been reduced to a smoking ruin) I'll have to wait for a kernel update to see what happens - whether it simply installs the compiled modules into the new kernel, re-compiles them (and, if so, whether it needs new headers), etc. I suspect it'll simply install the compiled modules, fetching new driver versions as and if the yaVDR guys update this package - fingers crossed, anyway. I'll let you know what happens, just in case it's useful for anyone else. |
| find quote |
Prof Yaffle
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-05 19:47
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:... 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
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-18 14:43
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
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-18 16:56
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_initand 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
Member+ Joined: Mar 2011 Reputation: 3 Location: UK - in the middlish (mostly). |
2012-08-18 19:58
Post: #19
Make that last line IF I get anywhere...
|
| find quote |
speed32219
Fan Posts: 429 Joined: Feb 2007 Reputation: 0 |
2012-08-20 04:02
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 |

Search
Help