On Monday March 13th 2023, our hosting provider will have a maintenance window for our server infrastructure. During this window a cooling issue of one of the buildservers will be addressed, and our 10Gbit NAS storage connection will be made redundant.
This work will commence at 10:00 GMT and may last until 14:00 GMT. In this time window, there will be periods of unavailability to both this forum and the downloads.
Geplaatst door Gennar1
aan 24 januari 2013 - 18:29
Hi guys, recently I bought an ultra-cheap DVB-T stick form a Chinese ebayer that is based on the rtl2832 chipset with a new tuner: the Rafael Micro R820T. It is not supported by the current dvb-usb-rtl2832 OpenPli driver, but I found a new version of the Realtek driver that adds support for this new tuner. So I ported all our enhancements on the new driver version and I made a new patch for the ETxx00 3.6.0 kernels (see dvb-usb-rtl2832_kernel_3.6.tar.gz in attachment). It is a drop-in replacement of the current patch (there's no need to modify the recipe). This patch should also apply to older kernels (e.g. the 3.2 DMM kernel) but you may have to adapt the dvb-usb Makefile and Kconfig bits in order to apply it (not tested).
While I was working on it, I also added support for newer kernels (up to 3.8-rc4) and the current media_build experimental tree (http://git.linuxtv.org/media_build.git). Linux PC users can use the second patch (dvb-usb-rtl2832_kernel_3.8.tar.gz) to add support for the new rtl2832 devices to their distribution kernels (through the media_build script). A different patch is needed because in kernel 3.8 the directory structure of the media drivers has changed, so all the files have a different path.
I also implemented properly the get_frontend() ioctl on this driver, so now you can read the real tuning parameters from the tuner in Enigma 2 (Guard Interval , Code rate HP, Code rate LP, Inversion, ...). I hope this makes Ims happy ;-)
Geplaatst door Gennar1
aan 13 januari 2013 - 17:17
Hi all, the patch in attachment fixes the problem with the af9035 driver and the new revision of the A867 stick (the "DP7" revision). The fix has been successfully tested by Drake.
Pieterg, can you add this patch to the Xtrend kernels? Also, the patch tda18218-7mhz-lopass.patch should be deleted, as it was only required by the old out-of-kernel af9035 driver (due to a wrong setting of the IF frequency). The new af9035 kernel driver does not need it anymore.
I have a chip version 2, from what I understand the path solves the problem of access to the USB chip to version 1 So do not install this patch.
The fix will benefit all models. Anyway, I'm not sure your problem is related to this bug. Nevertheless, it's worth a try.
As the ET support explained, this driver has been under heavy development for the last 2 kernel cicles. All the patches from kernel 3.4-rc* are already merged in the OpenPli 3.3 kernel. This last one was posted just a couple of days ago and it's not even on the experimental tree yet. So there is nothing more we can do (as we don't have the hardware in our hands).
I believe this is incorrect, decoding is not a lossless operation, every decoder produces different output. The algorithm used allows specific optimizations to improve quality. At least this was the case for MPEG2 decoders, don't know if this has changed in H.264.
You are right about MPEG2: this standard used a real DCT transform, which required some approximation to be computed on hardware without a FPU. The MPEG2 specification defined the maximum error tolerated to be compliant to the standard, but different implementations could produce different results.
With H.264 this is completely solved using only integer transforms that need no FPU calculation, so they can be computed with no approximation using only integer math. So every H.264 decoder produces exactly the same output. There is no room for shortcuts: if an H.264 decoder produced a different output than the reference decoder, it is not compliant to the specs so it cannot be called an "H.264" decoder.
Geplaatst door Gennar1
aan 14 februari 2012 - 02:56
Uh, you are right, the USB id of the A825 is in the current af9035 driver, so it is already supported.
Since it works well with both tuner, it probably uses two mxl5007 or two tua9001 tuners.
The memory problem is not present on the ET9xx00 boxes (at least on dvb-usb drivers), but I read of many VU+ users with this problem so it must be due to their new drivers. Probably in the Vtuner they allocate and free some big coherent memory buffer at runtime, which is prone to fail sooner or later on MIPS hardware due to memory fragmentation. A similar issue is plaguing the em28xx driver on the ET9000 (and I have a fix under test in this moment).
Geplaatst door Gennar1
aan 12 februari 2012 - 01:20
It has completely nothing to do with that.
An mpeg transport stream can hold all sorts of video and audio codecs for both sd and hd.
If you sell your product as being able to play "mpeg transport streams" it should at least be able to play the most common codecs, like mpeg2 and avc. If it can't they're at least cheating, but then blaming the stb/enigma is... I don't have words for it!
The Oppo guy was probably saying that they support the DLNA specifications, not the DVB specifications. In DLNA the only mandatory video codec for TS is MPEG2, AVC is optional as almost every other codec, so it can be considered "non standard". The reason behind it is that in DLNA you want a simple common profile that can be supported by all kind of devices. That said, I don't see any good reason why the file should not be playable: probably it is just a mis-detection of the file format.
Geplaatst door Gennar1
aan 17 december 2011 - 19:17
Trying to find a decent usb dvb-t/t2 tuner for the ET9200 now.. googling around for a while I landed on this one, looks really neat. Anyone knows if it works with the ET9200?
Geplaatst door Gennar1
aan 10 december 2011 - 20:05
Hi all,
in attachment 2 new patches for DVB-T drivers in kernel 3.1.0.
The first one fixes SNR display in Enigma2 (and also with Kaffeine under Ubuntu) for the PCTV 290e DVB-T/T2 stick.
The original driver outputs the SNR as dBx10; this value is now capped to a max SNR value (dependent on the delivery system and modulation type) and then scaled to the full range 0-65536 that is displayed by the coloured bar in Enigma2. The result is very nice.
The second patch is a minor fix to the xc3028 tuner that makes possible to tune VHF channels.
Geplaatst door Gennar1
aan 28 november 2011 - 01:41
Nice work Ambrosa. It is worth mentioning that someone else has posted a patch to add support for kernel 3.2-rc2 (the latest version) to your source tree: