TBSDTV Community Forum

No more precompiled libraries nor the TBS v3.0 tree. You can now use a much more current tree (Thanks Igor Liplianin) and make changes you wish without those precompiled lib's getting in the way. This patch has all the Prof 7301 and 7500 changes plus the spectrum scan and IQ plot changes too.

Download and unzip the patch from my google drive
https://docs.google.com/folder/d/0B7PjDRC3SaJxZEh1SVRZZkVqZDg/edit


hg clone https://bitbucket.org/liplianin/s2-liplianin-v37
cd s2-liplianin-v37
patch -p1 < ~/Download/UDL-beta-v37.patch
make menuconfig
make
# I like to unload my kernel modules before installing, up to you
sudo make install
# restart your computer or reload your kernel modules


If your using other TBS devices this tree doesnt have support for them, the only TBS product I have is the 6925 so I dont feel comfortable adding other devices for which I can test.

Try it out and report back, Thanks

UDL
http://updatelee.blogspot.com

Does it mean that Liplianin's branch fully supoorts TBS hardware?

Ive branched off, Im not using the v4l tree with the saa716x code from powARman (very close to liplianin's)

https://bitbucket.org/updatelee/v4l-updatelee-git

And no liplianin doesnt really support any additional TBS cards other then the ones already supported by the mainline v4l tree. Mine only support a limited number of TBS cards, many use closed src binaries. The 6925/5925 were pretty much already open source minus a very minor voltage controller module that was super simple to reverse engineer, no idea why they even went that route in the first place for such a simple piece of code.

You wont be able to use my tree with TBS binaries, too much has changed in frontend.h and dvb_frontend.h Crazycat does have a tree that supports TBS binaries and has tried to implement as many feature updates as possible into that tree, but the precompiled binaries really halts development in alot of areas.

UDL

UDL

Updatelee open source driver works perfect for tbs6925, but when try to read data from all pids there is BB frame header bytes (0X42 0X0 0x0 0x0) between 0x47 (mpeg header byte). Does anybody knows what would be the reason for this. It is TS stream not GS. I'm just curious...

Your getting bbframes with my tree and not the tbs one? I dont know thats pretty odd, I stream 0x2000 quite often, probably more often then not. Just easier. and have no problems with packets. I'll look into it when I have some time,

UDL

thanks for the quick responce. it's all my fault, it is GS NOT TS. however ther is MPEG byte (0x47). Do you have any success with BB processing. Because i'm not sure how DMX pass trought MPEG in GS mode.

GS streams are pretty rare here, I havent had any time to play with them. Honestly I dont really like how the DMX kernel code works, I modified the tree to support different size packets, but havent done anything with creating dynamic size packets based on the BBFRAME info.

Is GS always the same size, I understand they can pick any size, but once they pick a size is it always that size? or does it change all the time? one packet this size, next packet a completly different size?

UDL