Package Details: dvb-usb-rtl2832u-openpli 20130918-6

Git Clone URL: https://aur.archlinux.org/dvb-usb-rtl2832u-openpli.git (read-only, click to copy)
Package Base: dvb-usb-rtl2832u-openpli
Description: Linux module for the RTL2832U DVB-T USB2.0 device
Upstream URL: http://openpli.org/forums/topic/20899-rtl2832u-chipset-support-proposal
Licenses: GPL
Provides: dvb-usb-rtl2832u
Submitter: R00KIE
Maintainer: R00KIE
Last Packager: R00KIE
Votes: 18
Popularity: 0.000000
First Submitted: 2012-04-02 18:06
Last Updated: 2017-07-23 11:59

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 ... Next › Last »

R00KIE commented on 2014-09-02 08:19

I too was looking in the repos at sourceforge and I couldn't find the patch I'm using here, I could find an older one though.

What I suggest you do is try without this driver, if you are using either linux or linux-lts from the official repos there is support for the rtl2832, like Gringo says.

I'll ask on the openpli forums what happened to the patch.

Gringo commented on 2014-09-02 08:10

Perhaps the patch has been included in the openpli software now? I cannot find the path anywhere in their repository. It seems a lot has changed. You could try to install without the patch and see if that works. Unfortunately I don't have the time to thoroughly check this myself at the moment.

@monyo: note that this driver is not required in most cases. The Linux kernel includes a 'bare bone' version of the driver since version 3.7.4, i.e. without support for the remote control and such.

monyo commented on 2014-09-02 05:14

I got 404 error when downloading the patch. Could you fix the link? Thanks in advance!

R00KIE commented on 2014-05-18 20:03

@Lenny
Thanks for bringing this to my attention. Package update.

Lenny commented on 2014-05-18 18:25

Upstream changed url for rtl2832 patch.
New git raw url: http://sourceforge.net/p/openpli/openpli-oe-core/ci/master/tree/meta-xtrend/recipes-bsp/linux/linux-etxx00/dvb-usb-rtl2832.patch?format=raw

R00KIE commented on 2014-02-23 16:02

You may not need to recompile the driver on every minor kernel release but you never know when and how it's going to break if you don't ;)

As for the remote, I'm not using it. When I bouth my receiver I took the time to make the remote control work but never published the patch, I think a different patch may be needed for every different remote so it's not really worth the trouble.

The guys at openpli don't bother with it either, I believe they use dedicated IR receivers and configure lirc to use that instead of the one on the dvb receiver.

trzalica commented on 2014-02-23 15:19

Thanks for reply to @R00KIE & @Gringo!
I don't need to recompile this driver and reinstall it after each small kernel update but sometimes it brakes but that isn't big deal. It important that now everything works! :) I don't use driver in kernel because it simply doesn't recongnize my device (I look through terminal and it doesn't show DVB-t device).
Just one more small question: you're using remote controler you get with your DVB-t card or?

Once again thanks for answers!

Gringo commented on 2014-02-23 15:14

@trzalica: lol, I see that Kaffeine is a media player, while Caffeine is a screensaver blocker. Confusing!!

R00KIE commented on 2014-02-23 14:50

Using this package means __recompiling__ and __reinstalling__ the package on every kernel update as even minor updates can break the driver.

R00KIE commented on 2014-02-23 13:57

Like Gringo says I only package the driver, if the problem was a missing vid:pid I suppose I could manage to add it (assuming that all the harware in the receiver was supported), however my programing skills and knowledge about the driver and usb/dvb subsystem would not allow me to do more.

Even upstream, which in this case is the openpli community, probably can't do more than they already have, which is "fix" the driver provided by realtek and make it compile cleanly with modern kernels.

@Gringo
What is included in the kernel is a different driver, written from scratch, and not this or any of the other drivers floating around, I beleive the reason for doing this was license concerns.

@all
That said (and I've posted this view before), from my experience, I'd say that for normal everyday use the driver included with the kernel works better if it supports your hardware.

This driver is most useful if and when you need to position an antenna, because it will report sane snr and signal strength values (and tools like femon will properly report when the receiver has a lock on the signal).