for RPi Feature #4572: OMX Support - Tvheadend
for general watch Commits · tvheadend/tvheadend · GitHub
x86 is basically working besides bugs with deinterlacing
Posts by CvH
-
-
KD and UM are known to act stupid, working setups broke from one to the other day due "changes" at their infrastructure (whatever that means).
-
do you just want to edit the estuary skin ?
if so you can justcp -R /usr/share/kodi/addons/skin.estuary/ /storage/.kodi/addons/
that copies the estuary skin to your normal addon dir and there it "overwrites" the files that are at the image -> you can edit whatever you like
-
from hw/driver side it should work but currently some bug prevents it at Tvh side
-
did you a clean build between 8.0 and 8.1 ? (make clean) ?
-
the RPi version is not functional at the moment (it simply doesn't work from Tvh side)
you need to make some new "codec profile" then create a new stream profile - but like said currently not working for Rpi
-
which standard do you use ? As you linked to newegg I guess USA/CA ?
-
do you use an Intel/AMD HTPC ?
-
It is likely a Intel GPU problem, I have basically the same behaviour (it is getting worse and worse since LE7).
To "fix" it just run the edid script, fixed it for me.
-
Maybe someone can compare, if http://vlc-bluray.whoknowsmy.name/files provides the same KEYDB,cfg file as "the official server"?
is an older version, so likely new entries are missing
-
oscam-emu is a bit shady (legal wise), I would really not include it at the repo
But I see no problem that someone offers it at the forum.
-
the source of the "official" keydb is down for some reason
so all links are down too
-
tx will add this hopefully to final release
-
Can anyone compile an actual libreelec including the firmware from:
just place the fw here how_to:add_firmware [LibreELEC]
and reboot
thats a bit silly but if it works I pr the change asap
-
well I dont know how to bisect between trees
you need to build your own kernel and test it, the change is somewhere at 4.9rc1-4.9.rc2
-
Could someone tell be wich is the kernelversion the problems began with ?
the problem is somewhere between
GitHub - torvalds/linux at 6b5e09a748ad0a0b198d0e268c7e689044bfe48a and GitHub - torvalds/linux at 2937f375751922ffce9ef1d5fa84491840b0c8e0
-
Sat>IP works over UDP, packets that get dropped are lost forever - they won't get resend like its done with TCP.
Depending at you home network the packet drop could be more or less. If too much is dropped the stream gets errors that you can actually see at the pic.
Known things that might lead/tend to advanced packet drop:
WLAN, DLAN, RPi, more then 1 switch/router, heavy traffic at network
-
didnt work on ksazq build
this is expected, these builds using 64/32 builds and are not yet supported by the LE build system - pls contact kszaq if he might do a build
