Posts by noggin

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)

OK - checked some 5.1 stuff from BBC One HD in the UK.

This is from last Sunday's episode of Cormoran Strike - both DVB-T2 AAC 5.1 and DVB-S2 AC3 5.1

Both play as files and from within the TV Headend PVR client with no problems on my Haswell Celeron Chromebox running LibreElec 8.0.2. I'm configured for 5.1 output over HDMI and my amp is being sent 5.1 PCM with the AAC clip and bitstreamed AC3 for the AC3 clip. I have no audio glitching.

My AAC 5.1 BBC One HD recording has the following properties from Media Info (I've snipped the filename, and the EPG EIT stuff from the bottom) BBC HD stuff carries either a 2.0 or 5.1 AAC main programme channel, and then a mono additional audio description channel (for people with visual impairment to audibly describe visual action) which receivers add to the main programme sound feed.

(You'll also note the video is flagged progressive. This is because UK H264 HD encoders on DVB-T2 switch between i25 and p25 encoding on-the-fly. The Media Info is actually for a short clip I created using 'dd' to crop the first 500MB of the file, as the recording started early and started with the end of a 2.0 AAC show)

Format                                   : MPEG-TS
File size                                : 200 MiB
Duration                                 : 6mn 46s
Overall bit rate mode                    : Variable
Overall bit rate                         : 4 130 Kbps

Video
ID                                       : 6601 (0x19C9)
Menu ID                                  : 17540 (0x4484)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : 27
Duration                                 : 6mn 45s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Audio #1
ID                                       : 6602 (0x19CA)
Menu ID                                  : 17540 (0x4484)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Muxing mode                              : LATM
Codec ID                                 : 17
Duration                                 : 6mn 46s
Bit rate mode                            : Variable
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 48.0 KHz
Frame rate                               : 46.875 fps (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : -806ms
Language                                 : English

Audio #2
ID                                       : 6606 (0x19CE)
Menu ID                                  : 17540 (0x4484)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : HE-AAC / LC
Muxing mode                              : LATM
Codec ID                                 : 17
Duration                                 : 6mn 45s
Bit rate mode                            : Variable
Channel(s)                               : 1 channel
Channel positions                        : Front: C
Sampling rate                            : 48.0 KHz / 24.0 KHz
Frame rate                               : 23.438 fps (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : -611ms
Language                                 : English
Language, more info                      : Visual impaired commentary

Text
ID                                       : 6605 (0x19CD)
Menu ID                                  : 17540 (0x4484)
Format                                   : DVB Subtitle
Codec ID                                 : 6
Duration                                 : 6mn 44s
Delay relative to video                  : 2s 261ms
Language                                 : English

Menu
ID                                       : 6600 (0x19C8)
Menu ID                                  : 17540 (0x4484)
Duration                                 : 6mn 46s
List                                     : 6601 (0x19C9) (AVC) / 6602 (0x19CA) (AAC, English) / 6606 (0x19CE) (AAC, English) / 6605 (0x19CD) (DVB Subtitle, English)
Language                                 :  / English / English / English
Service name                             : BBC ONE HD
Service type                             : advanced codec HD digital television

Quote from backslash

I am facing a strange issue with AAC 5.1 here in Germany using latest LE and Tvheadend for watching DVB-T2. While watching live tv with AAC 5.1 audio I have no issues but if I try to watch a recording (e.g. of the same programe) which includes AAC 5.1 audio I am facing annoying audio hick-ups. Is Kodi relying on differtent audio decoders for live tv and recordings? This is pretty annoying because any recording which includes AAC 5.1 audio is sadly unwatchable. I started using Kodi with Krypton and the DVB-T2 release here in Germany and was facing the issue independent of LE and Kodi Krypton version. I installed 8.1.1 beta recently from scratch and the issue remains. Any ideas?

The UK has been using AAC 5.1 for a while on DVB-T2 (we're AC3 on satellite but AAC on terrestrial) and I've not noticed any issues with playback (though there have been some 5.1 -> 2.0 mix down issues where I don't think AAC mix-down metadata is followed as well as AC3).

I'll check a recording of a BBC One HD 5.1 drama I made over the weekend with various LibreElec installs - as I have it in both AAC 5.1 (from T2) and AC3 5.1 (from S2).

I'd heard Germany was using E-AC3 on DVB-T2 (as France does on DVB-T for HD) - is there a split between broadcaster?

ALSO - have you tried watching the file outside of the PVR sub-system (i.e. playing it from Videos by mounting your Recorded TV folder as a source in Videos->Files or copying it to a location available to Videos->Files?)