Posts by noggin

Quote from tuep

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)

Quote from shablamy

I'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

Display More

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.

Quote from gdogg371

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)

Quote from chrisssj2

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...

Quote from wrxtasy

Believe us 4K HDR IS working. escalade must having been living under a rock or in a cave somewhere lately.

Maybe escalade is differentiating between "Support" (where it is clearly stated that HDR is not officially supported) and "Working" (which it clearly is)...

Quote from escalade

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 ?)

Quote from chewitt

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.)

Quote from polo_joe

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.

Quote from CvH

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?

Quote from superczar

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)

Code

echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

However,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.

Quote from pajtaz

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?

Quote from 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).

I'm guessing they move channels between cable frequencies and/or change mux parameters whenever they like, as they (like many pay-TV satellite operators) can control the platform (i.e. their set top boxes are able to be told about these changes transparently) and thus moving channels around (or changing mux parameters) causes them no issues. However for third party reception solutions, which aren't part of this closed ecosystem, the changes require some manual intervention potentially?

Another vote for the Digibit R1 here, running the third party SatIP-Aex firmware (which is effectively a Mini Sat>IP install). This allows far more complex LNB and Diseqc set-ups to be configured than the stock firmware, and supports some very clever uses of the internal RF input->Internal Tuner 4 x 4 matrix switch that the stock firmware doesn't.

If you have something more complex than a straight forward Quad/Quattro LNB set-up then the R1 with SatIP-Axe is a very good solution.

The NAS option is a neat one - but if you are going for a standalone solution then make sure you run LibreElec on it, and ignore the Android aspect. Most reviews will concentrate on the Android side and won't be relevant when the box is running LE.

In my experience the Android experience on these boxes is pretty dismal - whereas once you are in LibreElec they fly. I have an S905 based 1G/16GB MX box which I have reflashed LibreElec onto (so no dual boot) and it works very well as a Kodi player (2160/60p HEVC stuff is output at 2160/60p i.e. 4K - with no problems, and USB DVB-T2 tuners work fine with TVHeadend running on the box - though I haven't used the solution in anger with external storage as it isn't my main PVR solution.

Quote from jnye6601

Thanks all. AverMedia support responded today. They advise that said tuner is Windows compatible only. Any suggestions for a compatible tuner, or how to connect my box to a windows unit driving the tuner?

Make sure you go for one with driver support on the Linux TV Wiki. The Hauppauge models are usually well supported.

Most of us in these parts are probably DVB users (Europe, lots of Asia, Aus/NZ etc.) so our tuners aren't compatible with the ATSC standard, so we can't recommend particular models based on real-world usage. (I have a pile of DVB-T/T2 tuners...)

The BBC retired the BBC One HD logo a very long time ago.

BBC One HD on DTT and DSat is 1080/50i (aka 1080i25). However the encoders on DVB-T2 use a dyamic i25/p25 switch to improve picture quality for a given bitrate (as DTT runs at a lower rate) You need to make sure that you are deinterlacing properly (MMAL - Advanced enabled) to get decent quality, and also need to ensure you're video output is 50Hz not 59.94/60Hz. (Either fix it at 50p or enable 'Adjust Refresh Rate on Start/Stop' in Player settings.

The iPlayer streams (apart from on Sky which uses 1080i downloads) top out at 720/25p or 720/50p - and are lower resolution (and have a lot more compression artefacts on busy stuff, particularly native 50i/i25 stuff)

Quote from Iridium

noggin - You could try contacting AVerMedia and ask if they know of any linux driver (depends on what differences there are). There may be something already compatible with your device like the A835.

I don't have the problem! Was just trying to help the OP. I'm in DVB-land and happily running a mix of DVB-T/T2 and S/S2 tuners with no major issues

Yep - that log shows that the tuner is recognised as a USB device, but nothing more than that (i.e. it isn't recognised as a TV tuner and initialised).

AVerMedia - LinuxTVWiki doesn't show Linux support for the A837 or H837 - so it looks like that tuner is a Windows device but without Linux support.

I'd always recommend consulting the LinuxTVWiki to check support before buying a device (though if you already have one - that's a moot point)