Another big plus of the TV uHAT is that it works with the stock Linux kernels out of the box - no need to mess around with the out-of-tree DVB drivers.
so long,
Hias
Yes - and as it is a full HAT with an onboard ID EEPROM - it identifies itself automatically so not even a need to manually edit config.txt to add a device tree.
Hi all
Just to let everyone know that the new DVB-T/T2 Raspberry Pi TV uHAT (released recently by Raspberry Pi) works fine in recent builds of LibreElec on a Pi 3B+ (it works on a Zero too - though it's a little sluggish) with the standard LibreElec TV Headend server.
The TV uHAT is neat, as it uses an SPI connection to the Pi, rather than using the single USB bus, so it removes the DVB I/O from that bus (which can be a bottleneck). It will stream a full DVB-T/T2 mux across the SPI - so you can stream (and I guess record - subject to USB bandwidth if you're recording to USB storage) all the channels on a given mux. In the UK this is neat as all the main 'big 5' HD services are on the same mux (PSB 3/BBC B)
It's pretty good value at £20incVAT
If you are looking for a neat, single DVB-T/T2 tuner it's worth a look.
The image was LibreELEC-TinkerBoard.arm-9.0-nightly-20180709-2f5a3b0-rk3288 found on the testing page. I have already removed it from my sdcard, and if you consider it "no problem" I'm totally fine with that. Good luck trying to find someone who agrees with you and likes to watch slowmotion video where audio and video are completely out of sync.
You are missing the point I think.
You're running an alpha release of software that is actively being developed and in doing so you are effectively agreeing to help developers fault find it, as they are sure it has loads of bugs in it (that's what running Alpha software is all about)
For your fault report to be investigated you need to upload a log for developers to have any hope of fixing it. That's the quid pro quo for developers making nice stuff that we get to use for free...
You'll find no log = no problem is a common attitude for developers here. Log files are vital to troubleshoot issues - as they tell developers far more about an issue.
Apologies for necro-posting - but I've been playing with this on a Pi 3B+ with an Adafruit 128x128 1.5" OLED display (SPI and supported nicely by fbtft)
This plugin is really encouraging - did it move forward?
Getting the graphics version recognised would be a big step forward. However, is there a version of LE that handles HDR10 correctly and forwards the required flags to the display? If not, there's little point in taking things forward when there are more established solutions around.
If you want HDR10 support under Linux, you are currently pretty much limited to ARM solutions.
The AMLogic S912 and S905X both support HDR10 flagging and up-to 2160/60p HEVC decode and output.
For x86 HDR, at the moment you are stuck with Windows, and it's not as straightforward.
At the moment I've not seen anything that flags HLG HDR output over HDMI, though hopefully as HLG takes off this will change.
The BBC iPlayer is doing a number of 2160/50p HLG HDR shows this year I believe, and have already shown Blue Planet II and a minor live Rugby League match (as a quiet test) this year.
Kodi supports 'status' output to VFD type displays but there's no function for external controls like that.
At one point weren't there LCDProc drivers for simple VGA screens? (At least on PCs)
AIUI the Pi + Touch screen + HDMI is more complex, as whilst you can run both separately (as you can HDMI and a GPIO VGA/LCD screen) there are quite heavy limitations (one is really only available for OMX?)
It's a Samsung LE40C750.
I am assuming the TV is just fine. With raspberry there have been never issues like that.
Ah - I thought you were running 4K. My bad.
So beside the issue with loosing the hdmi output which can be luckily fixed also by restarting tv instead of pulling cables I still have another issue with this build.
Under Milhouse build I could enable 25Hz mode. With your Build piotrasd I don't have to work with the whitelist but the 25Hz mode is not available. This leeds to stuttering playback when the display mode is set to 50Hz I don't know why this is, because it should just display a frame two times, but it is very noticeable and not possible to enjoy.
Edit: I tried to get everything as much as to default as possible. So I deleted my autotstart.sh, I created the xorg.conf like you suggested, run getedid delete, and later getedid create.
Now I have output on start, the 25Hz movies are still displayed with 50Hz but now the stuttering is gone. If the driver patch comes, it is nearly perfect, beside one bug.
But on one movie I have a new bug that during playback a mouse cursor appears in the center of the screen.
You don't have a Panasonic OLED TV do you? There have been known issues with some models in 50Hz mode - enabling GAME mode removes them (but then displays 24p at 3:2 60p)
There's also a known issue with the Sony XE900 series in 50 and 59.94Hz modes where pairs of frames are dropped, then different pairs are repeated (as a pair - so you get a motion judder on native 50Hz stuff) It usually happens on cuts. GAME mode removes it... (Sony are about to swap out me XE9005 for an XF9005 because of this)
Display MoreI've owned my TV since 2015 and to my astonishment it supports up to HDR10bit 4:4:4 and plays Dobly Vision(12bit?!) content.
My LG TV EDID reports:
420,10bit
420,8bit
444,10bit
444,8bit
422,10bit
422,8bit
rgb,10bit
rgb,8bit
I enabled the HDR setting in Kodi and rebooted, all works just fine.Does that mean if the TV plays a file encoded with HDR content, that I have these supports? Or is there another way of checking? I must say the quality is incredible(could be a placebo), but weirdly when I reinstalled my system yesterday using my crappy Samsung work monitor from 2010(max res 1080P), it also played the 4K HDR files?! dafuq
Beware - support for 10 or 12 bit content doesn't mean support for HDR content - nor does it mean your TV has a 10 or 12 bit panel.
SDR video can use 10 or 12 bit video, and support for accepting 10 or 12 bit SDR video is pretty widespread - even if your panel is only capable of bit bit or less display.
Hi. I am looking to DIY build a 4K HTPC with a 60hz 4K capture card to use with sky Q. Because the viewing card has to be paired with the box, I cannot use a third party HTPC directly, so instead a capture card.
I’ve got a basic version of this set up working with a Colossus 2 on my desktop PC, but am struggling to find a conclusive answer around a 4K PVR set up on Librelec.
Could someone please help?
Thanks
If you are using a British SkyQ then you will need a 50Hz 4K capture card. Sky Q is 2160/50p output (it's 50Hz like all UK TV) - not 59.94p.
(However most PVR support in Kodi is for tuners rather than capture card solutions, and Sky Q will almost certainly have HDCP on its output which will be another hurdle)
Now escalade there is not even HDR support... While that has been clearly reported working.. What is going on...
No matter if someone says dolby vision is working or not.. i can't believe either answer. because everyone seems to have a different one..
Most (all?) LibreElec builds are not officially supporting HDR (probably because it's new, and a whole world of hurt) - but irrespective of official support, lots of us are getting what appears to be proper 10 bit BT.2084 BT.2020 replay with the correct metadata from 2160p HDR10 HEVC files...
There's no HDR support on Linux, Dolby Vision or not.
Eh?
LibreElec and OSMC on my two S905X boxes happily play back HDR10 HEVC content with the correct PQ ST.2084 OETF (as used by HDR10) flagged, the correct Rec 2020 colour space flagged, the correct primaries (Rec 2020 or DCI-P3) and the correct Max/Min Luminance metadata via HDMI Infoframes. Confirmed this with an HDMI analyser downstream of my boxes.
If you enable 10 bit output on the S905X from the command line (on LibreElec you do this before you play a video, on OSMC you can do it and then restart Kodi) you get 10 bit output too (by default current S905X builds send 8 bit - which is not good for HDR)
They don't handle Rec 2020 HLG properly - but CNX-soft reports that the S905X doesn't support HLG, and the S905L is needed for that. (Annoying as HLG is just Rec 2020 SDR with an 'HLG EOTF present' flag - no need for other metadata...)
Both LibreElec and OSMC are Linux...
(Or do you mean there's no HDR support on x86 Linux ?)
In past experiments on the original 100BaseT equipped AppleTV (which is why LE/OE have support for nearly all the chips involved; I tried them) moving to a USB gigabit adaptor lifted speeds from ~11MB/sec to a whopping ~14MB/sec. Why so little? .. because running networking over the USB stack requires a lot more computational overhead than using Ethernet, and this taxes the CPU and negates many of the theoretical gains (even at USB 2.0 speeds). I would be very surprised if anyone reports a significant user-experience improvement using one.
TL;DR .. cheap boxes with 100BaseT are cheap boxes with 100BaseT .. caveat emptor
Hi there
Looks like things have improved then ; Running iperf on Raspberry Pi 3 | NetBeez
Quite a few people have been using Gigabit->USB3 adaptors on Raspberry Pis to improve the network performance a bit (doesn't get round the shared USB 2.0 bus but that's a separate issue related to the Pi)
With the 10/100 internal adaptor they are getting iperf figures of ~95Mbs on a Pi 2 or 3, with a USB->GigE adaptor they are getting 170-220Mbs. (Pi 3 performs better than Pi 2) This is around double the performance of the internal 100Mbs (which itself is performing well for a 100Mbs solution)
Wouldn't it be fair to expect similar results on similar ARM chips?
AIUI the USB->GigE solution is likely to be a way round the S905X internal 100Mbs Ethernet limit for >100Mbs content, such as high bitrate UHD rips that a larger buffer doesn't solve (i.e. if the content is not just occasional >100Mbs spikes). AIUI one UHD title that is quite taxing is one of the few (only?) 2160/59.94p releases - Ang Lee's 'Billy Lynn's Long Halftime Walk' (which was shot at 119.88p, and release at 59.94p on UHD)
(For those wondering - USB 3.0->GigE adaptors do work in GigE mode when connected to USB 2.0 ports - assuming there is driver support. You can't saturate the GigE connection with a USB2.0 connection, but you can get significantly better throughput than a 100Mbs Ethernet connection.)
Could someone tell me If its possible and how to install this builds on emmc on rock64?
I bought the Pine64 USB->emmc adaptor and flashed it as I would a uSD card.
Don't run Tvh servers for more then 1-2 connections/tuners at the RPi, there are so much limitations due the "not that good" usb-lan connection including packet drops and bottlenecks that it is not a save bet. Better user for it an Odroid_C2 - same Price level but much better performance.
Though downside is that the standard kernel for the C2 is older and doesn't have as many modern DVB devices with decent support? Or has that changed?
However, I do have a very fundamental question
I tried playing back a 10 bit video which was reported by the AVR as 8 bit
Subsequently, I enabled 10bit on the box by setting the class attribute as follows (on the original kszaq 8.2 commit)
Codeecho '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attrHowever,now the AVR reports 10bit>10bit at all times, i.e. not only while playing a 10bit video but even regular 8 bit videos
Short of copying said files on a USB drive and running a visual comparison between playback off the USB drive on the TV vs Kodi, is there anyway to conclusively determine what bit depth Kodi is actually sending out the output as?
My guess is that the echo command above sends a code to the HDMI TX subsystem to force HDMI output to 10 bit permanently.
This has no massive downside for 8 bit content (there should be no visual difference between sending 8 bit content as 8 bit and sending it as 10 bit with 00s in the 2 least significant bits - unless your display dithers 8 bit content to 10 bit) but it does mean you can't tell 8- from 10-bit content from the output format.
I use HDHomeRun 4DC (HDHR3-4DC). It's great but it's an overkill if you only need one tuner. I sold my USB tuner Hauppauge WinTV DualHD since I got the HDHomeRun 4DC. I think the WinTV Dual is ok but I believe the support is there for only one tuner. There's a whole discussion on LibreELEC forum about this.
Otherwise there should be other USB tuners that you can use. The only thing I can say is that having one box (your Raspberie Pie 3) doing TV tuning and recording using the USB tuner might slow it down too much. My Cubox could not handle watching TV with the USB tuner and recording. Maybe for this reason a network tuner is the better option. Just my thoughts.
The Pi B+/2B/3B shares one USB 2.0 connection bus across all 4 USB 2.0 sockets and the Ethernet port (which is 10/100Mbs). You will therefore probably have similar bandwidth issues whether you use a Pi for USB tuners or Network tuners. For a single tuner set-up you should be OK - but if you are looking to record multiple channels from different muxes to a USB drive (rather than SD card - which doesn't share the bandwidth) and watch live, I'd look at splitting your PVR backend (not just using a network tuner) to a more suitable platform.
The HD Homerun tuners are a good solution though - particularly if you are using platforms with older Linux kernels with older DVB driver support.
I think Silicon Dust are about to/have just updated the product line to include new Twin and Quattro models?
