Posts by noggin

  • LG C3 OLED TV and Libreelect on the Pi4b - PC Mode Issue

    Quote from HansM

    As of today, I *HAD* the same problem on my LG G4.

    After a lot of experimenting I came to the conclusion some signal is telling the HDMI port of the TV to jump into PC mode. Even the GUI at 1920x1080@60 jumped into PC mode.

    Then I tried @50: no PC mode. tried @30: no PC mode. So started the whitelist with only 3840x2160@30: Happy times, no more PC mode!

    Added all the other modes one by one and tested. In my case, the 3840x2160@60 and [email protected] modes on the whitelist were the culprit. Should be the same for 1920x1080 but didn't tried that yet...

    Good luck with this 'typical feature' of your LG OLED TV.

    If you're outputting 24fps content in 30fps progressive don't expect hugely watchable results.

  • RPi3B+ and 1080p H265 files

    Quote from Seth

    Thanks for you reply. Tried what you said but at the end of the writing with RPI it said "ERROR : partition has no FAT file". Don't know if it's normal. I downloaded LibreELEC-Generic.x86_64-9.2.6. Maybe it's not the good file ?


    Thanks once again for you help.

    The x86_64 = Intel 64-bit architecture, which is not used by a Raspberry Pi. That's the wrong file for a Pi 3B+.

  • RPi3B+ and 1080p H265 files

    You don't need to do any image extraction - Raspberry Pi Imager, and Balena Etcher (both good burning tools) - allow you to flash an img.gz file directly to your uSD card with no requirement to do any processing to the downloaded file (the tool handles the compressed file internally).

    You also don't need to format the uSD card prior to flashing - the flashing process writes the image (including the disk formatting data) to the card (it will usually re-size the drive partition to maximise the uSD Card capacity on first boot)

    If you're using Windows you can probably use the LibreElec USB-SD creator tool as well as a third option along with the Pi imager and Balena. I usually use Balena.

    The most common issue I've had with uSD cards not working is failure of the uSD card... I used to use a variety of brands (often whatever I could get a good deal on - but had a number of failures) - I then switched exclusively to Samsung EVOs and have had no issues since. (I'm not saying other manufacturers are terrible - just that my 'sample size of 1' experience is that Samsung EVOs work reliably for me. I don't use uSD cards on my Pi 5s though)

  • Getting TVheadend to work

    Quote from Billzilla

    No, I use a VPN that virtually places me in HK. :)
    I'm actually on the Gold Coast, Australia.


    If you're in Aus - then enter your details here https://myswitch.digitalready.gov.au and you will get a couple of options on the left including "Channels for" and "More Coverage Information".

    The first of these will give you a list of channels and the frequencies those muxes are on.

    If you're happy to screen shot that list we can help ensure you have the right muxes set-up in TV Headend. The second will let you know the various transmitters that you could be receiving - but I expect the first choice of the website for your postcode is what you should expect to be receiving in most cases (and if your transmitters use Single Frequency Networks within the same area the frequencies may be the same anyway)

    e.g. me just typing in Gold Coast QLD gives me these frequencies (dated 2016 - so it may be out of date - but equally stuff doesn't change hugely quickly in telly). Your post code may suggest a different transmitter which may be using different frequencies for your area. But here's what I got :

    This shows that this Gold Coast transmitter, Mount Tamborine, is in a UHF area, with SBS's mux on 613.5MHz, ABC's on 620.5MHz, Seven's on 627.5MHz, Nine's on 648.5MHz, Ten's on 641.5MHz and (not on the screen shot) Prime's on 655.5MHz, NBN's on 662.5MHz and Southern Cross's on 669.5MHz.

    If this is your transmitter - I don't think I see any of these frequencies in your TV Headend screen shot mux list - so that might explain why all of them fail to scan.

    If you delete all the muxes in the list you have and manually add one - say ABC - you may find that scanning it will add the other multiplex frequencies automatically (it's an option in DVB-T to do that and it's done in the UK. When I add the BBC PSB1 SD mux in London, all the other DVB-T mux frequencies automatically appear. If not just add all the muxes manually.

    I don't know that Mount Tamborine IS your Gold Coast transmitter - but hopefully this will give you a starting point.

    I believe Australia uses 7MHz wide channels, DVB-T (not T2) with 8k carriers, 64QAM modulation, with FEC of 3/4 and GI of 1/16 suggested (though I don't know if all muxes use these settings) - though depending on your DibCom tuner driver you may find that you can leave a lot of these on Auto anyway - though 7MHz and DVB-T are likely to be needed to be explicitly set, and 8k is probably a given. (Some low power broadcasters may use 16QAM or QPSK rather than 64QAM - local TV in the UK uses QPSK for instance)


    Shout if you need any help with manually entering muxes etc.

  • USB DAC Native DSD Support

    Quote from Da Flex

    Low-latency devices are used by musicians and audiophile people. The point is "low-latency", not the group of customers.

    As you can read in the second link of post #8, LE supports frequencies above 384kHz.

    Please learn the concept of an ASIO driver, and whats the challenge of writing low-latency code. Then you'll understand.

    Totally get the need for low-latency for music production (where you're often recording and playing simultaneously and need everything to stay in-sync) - I work in broadcast for my day job so totally understand the challenges of low-latency and the need for it in a production context.

    However I'm slightly puzzled by the need for the low-latency (and thus drivers that support it) in a purely playback setting where you just hit play and listen? Having some latency between hitting play and the music starting could be annoying (and if it's excessive and not accommodated for gapless playback I get that could be annoying) - but unless low-latency has another aspect I'm missing I'm not sure I see the need?

    Isn't ASIO specifically a Windows thing - not sure I get how it's related to Linux? Or am I missing something?

  • Getting TVheadend to work

    Quote from Billzilla

    Thanks, but I'm about 16,500 km from the UK and so not likely to pick up any signals from there.

    If you let me know where you are (nearest major city) (I guess in Australia or New Zealand?) - I can probably help track down the right frequencies to double check your TV Headend initial settings.

  • USB DAC Native DSD Support

    Quote from Da Flex

    In short: You want to use a USB audio interface, connect it to the AVR over S/PDIF, and play native DSD.

    This setup is generally possible with LE.

    Theory: I think the problem is the proprietary ASIO driver of your USB audio interface. Because it's proprietary, not all codecs are usable by LE. That means, LE offers all codecs, including hi-res native DSD, but the incomplete Linux driver only accepts lo-res DSD.

    Suggestion a): Use a USB audio interface, which is fully supported by Linux.

    Suggestion b): Use an RPi with HiFiBerry Digi2 Pro, as mentioned at post #8.

    DSD doesn't travel over regular 44.1-48k/16bit stereo SPDIF does it? (Though higher sample rate 192k/24bit SPDIF may carry some of the lower bitrate DSD stuff via DoP?)

    DSD64 (as used by SACD) is based on 2.8824MHz 1-bit Delta Sigma sampling (so needs 2.884Mb/s connectivity - which is more than the 1.536Mb/s of 48k/16bit stereo that regular SPDIF supports?)

    DSD512 is based on 22.5792MHz delta sigma 1-bit sampling - which is nearly 15x the data rate of basic SPDIF.

    AIUI there are USB standards for both DSD native transport, and DSD-over-PCM aka DoP (where DSD audio is kept as DSD format data but presented as if it's PCM at a high sample rate like 768kHz and sent using USB PCM Audio - in a standard that compatible devices then re-package back to DSD allowing native transport of the DSD Delta Signal bitstream. This requires the DSD to DoP packaging software/drivers to be DSD DoP-aware?)

    The OP is - I think - asking if it's possible to connect a USB Native DSD DAC to LibreElec to send DSD audio from LE to a USB-connected DAC which then outputs analogue - without transcoding that audio to PCM format audio for DAC decoding. This is a widely used route with smartphones, tablets, Windows and Mac PCs.

    I don't know what the Linux support is for DSD64-512 native audio transport over USB - either as DSD Native or carried as DSD-over-PCM.

    NB I'm not making any claims for DSD audio being better or worse than PCM audio, nor am I making any claims that DSD512 is better than 48k/16bit audio - but I know for some people it's important...

    What Yamaha amplifier do you have ?

    I take it from your post that it has a USB connector that will appear to connected devices as a USB DAC for both PCM and DSD audio? If you find out the USB IDs for it that may help?

  • Getting TVheadend to work

    Quote from Da Flex

    LE seems to get data for the first frequencies, but afterwards no more data are coming in.

    Maybe undervoltage inside of the receiver?

    Please provide a product link of your DiBkom 7000PC. Does it have an optional PSU, which you can plug in?

    The log indicates a Sony Play TV (sold for PS3 DVB-T reception) which is a dual DVB-T tuner USB DVB-T tuner (not T2, not S/S2 - not sure about DVB-C) and like most USB DVB-T (and T2) tuners is bus-powered with no separate power input option.

    With a decent (i.e. official Pi Foundation) PSU on a Pi it should be fine (I've run like that in the past)

    You usually only see external power inputs on DVB-S/S2 USB DVB tuners because they need additional power to drive an LNB, every DVB-T/T2/C USB tuner I've had since the mid-00s has been bus-powered - and I have a LOT of them...

    I ran 3 x Sony Play TVs for a while on an x86 Debian box to constantly tune all 6 UK national DVB-T muxes with no problems. (They were available for <£10 on eBay at one point - which wasn't bad value for a dual T tuner)

    Next step is to find out if the OP is tuning the right frequencies for their location, and getting services mapped etc.

    I have most models of Pi, a Play TV and some time today - so if the OP posts their exact set-up I can replicate in the UK from a blank uSD card on.

    So Billzilla which city are you in in which country, what model of Pi and what LE build are you running?

    I can see both DVB-T tuners in the TVH web if grabs you posted, but all scans have FAILed - which suggests one of these :

    1. The frequencies being scanned are wrong - or the settings for them like 16QAM vs 64QAM vs QPSK etc. are wrong

    2. The antenna connection isn't working (or an LNA setting isn't being set when it is needed ? Some DVB-T tuners have a Low Noise Amp option to boost the signal which can be enabled or disabled in the adaptor settings)

    3. The DVB-T tuner isn't being configured properly when it's detected by Linux and the OS thinks it's working when it isn't.

    4. The DVB-T tuner isn't being powered well enough by the Pi.

  • Getting TVheadend to work

    Quote from Billzilla

    The tuner worked fine for years before with the old box running on LE.
    It's apparently a DiBcom 7000PC unit.
    I have no idea what any of the details are of the TV transmissions around here sorry.

    I think some Dibcom modules need additional firmware in some installs. I don't know if LE ships with it.

    If you tell us the precise model of tuner (not just the chipset) - we may be able to assist.

    Also a log and the output of

    Code
    dmesg | grep dvb

    via SSH might be helpful.

  • Getting TVheadend to work

    One other thing to be aware of is that some USB DVB-T/T2 tuners need specific firmware to be installed even if their chipset drivers are in the Linux kernel. Though in those cases they usually don't show up in TVH.

    What tuner are you using?

    The pre-set muxes in TVH aren't always right - have you checked that the frequencies and modulation parameters that are pre-populated actually match your local transmitter as it currently is?

    These days I usually manually add my local mux frequencies to keep things simple. (I know the UK Crystal Palace transmitter frequencies off by heart now...)

  • Raspberry Pi 5: HDR not working


    Can you play HD Audio (i.e. Dolby True HD, DTS HD MA/HRA) with this set-up (I'm wondering if the TV-only EDID you are using doesn't have flags for the AVR-supported audio that the TV doesn't support ? Or it could be that with modern TVs they do flag support for this because eARC lets them pass it through?)

  • Raspberry Pi 5: HDR not working

    Quote from chewitt

    Nope .. at least not one affecting the 40K+ RPi5 users we have (else there'd be more folks showing up with issues).

    All the error messages flagged above are normal/harmless, and show it setting an HDR colourspace and 12-bit output. The RPi side appears to be doing everything correctly. I think the solution lies in AVR and/or TV settings, or port combinations.

    My guess is that it's something related to the Pi and AVR combo - other 4:2:2 2160p UHD HDR sources work OK - but the Pi 5 (and in some situations Pi 4) don't. There's a similar - though not neccessarily related thread here :

    Thread

    RPi 4/5 + Denon AVR - 4k60 'No Signal' issues

    Hi all, I have a small issue where upon turning on my TV/AVR (Pi is on 24/7), I have to change away from and back to the RPi source in order to get a signal. AVR is a Denon AVR-X 3600H.

    If the RPi has been idle for sometime, and my Denon AVR starts up with the TV input selected (usually use the TV remote power button to turn on), changing to the RPi/LE source results in 'No Signal'.... I then change the source to something else, then back to the RPi/LE and I have signal. I have CEC enabled on…
    tomstephens89
    December 29, 2023 at 1:36 PM

    If I get time I'll try to document my experiences with an LG C3 OLED and a Denon AVR-X2800H (4K/8K compatible AVR) with a Pi 4B and a Pi 5 on both the 4K and 8K AVR inputs (8K = HDMI 2.1 - so may have some other differences with 4K/UHD1 sources)

  • Raspberry Pi 5: HDR not working

    Quote from BallerShotCaller

    Thanks for that input noggin .

    In my case, I already tried to switch between 4K standard, 4K enhanced, 8K standard and 8K enhanced modes on that HDMI port. Nothing changed according to that issue.

    I have enabled 8K enhanced mode on all ports by default as the same limitations you described counts also for VRR support: Even when the TV's resolution capability is limited to 4K, to make VRR work on Onkyo receivers, in some circumstances 8K Enhanced mode has to be set for that specific HDMI port to make VRR work flawlessly.

    Yes - 8K Enhanced is probably code for HDMI 2.1 support - and VRR was added with HDMI 2.1 (My Denon, annoyingly, doesn't support VRR)

  • Raspberry Pi 5: HDR not working

    Quote from BallerShotCaller

    It also says traditional hdr false , same as on the Raspi 5 debug logs, but HDR works in this case!

    If I recall correctly the 'Traditional HDR' EOTF which is an EDID EOTF option is not supported by (m)any UHD HDR TVs - it's an old and deprecated HDR EOTF that has been replaced by HDR10 (aka ST.2084 PQ) and HLG (aka ARIB STD-B67). ('Traditional HDR', I believe, basically uses standard SDR Power Law Gamma but pushes it into the HDR range)

    (EOTF = Electro Optical Transfer Function - i.e. how video levels are mapped to screen pixel brightness levels)

    Quote from chewitt

    Then configure Deep Colour ON, adjust refresh ON, ensure no 4096 modes and 3840@60/59.94/50/30/29.97/25/24/23.98 are in the list, reboot for clean logs, then share a debug log showing something with HDR content.

    NB Deep Colour isn't always the term used to describe 4:2:2 12-bit 2160p support - it's often called 'Enhanced HDMI' or 'Enhanced 4:2:2 HDMI' on AVRs and TVs (and you often need to enable it on both - and on some TVs it's only available on some, but not all, of the HDMI inputs. My previous Sony Bravia only supported it on HDMI 2 and 3 - and it was still disabled by default, HDMI 1 and 4 were not able to accept that input format. My Denon AVR required it to be enabled too).

    However the Pi 4B and the Pi 5 have the same limitations (i.e. they don't support 4:2:0 output - which is all some UHD HDR TVs accept at 50Hz and above UHD resolutions)

    NB There are a number of reports of Pi5 models not playing nicely with Denon AVRs with UHD modes >30Hz. Some set-ups only work on the AVR's HDMI 2.1-enabled 8K HDMI inputs (even though the Pi isn't running 8K)

  • RPi 4/5 + Denon AVR - 4k60 'No Signal' issues

    Quote from Nekromantik

    thanks

    On the settings there is a resolution option and then max ui res. Whats the difference? I assumed the resolution option is only for UI anyway or is that for videos also?

    If you don't have whitelisting of different resolutions enabled - then Kodi will run at a fixed output resolution (with only frame rates optionally changing if you have the Player setting enabled to change refresh rate on Start or Start/Stop etc.)

    The UI resolution setting allows you - I believe - to run the UI at a lower resolution than the output.

    So you could run with permanent 2160p output - with frame rate (but not resolution) switching for 23.976/24/50/59.94/60 etc., with UHD/4K video played at UHD, and other content upscaled to UHD by Kodi, but with the Kodi UI running at 1080p resolution (upscaled to 2160p)


    If you whitelist 2160p, 1080p, 720p etc. resolution output modes at various framerates - then Kodi will switch to 1080p output when playing 1080p content, 720p when playing 720p content etc. However this will only happen if you have whitelisted suitable modes.

  • LibreElec Rpi4 TVHat TVHeadend - Recording Problems

    Quote from boragthung

    All channels on Freesat devices have OpenSky listed as epg source - none of them mention freesat as source, even though this is the predominant mux I schedule (11425H). I will experiment by removing the sky collector on my docker - but suspect I will have missing data for some channels.

    I just use the Open TV Sky UK EPG collector on my current main recording instance - which is using 4 tuners of an 8 tuner SAT>IP server, and that instance also has Freeview enabled for a Silicon Dust Quad DVB-T/T2 tuner. I have used the Freesat EPG source in the past - but my current set-up has been using Sky EPG data since I started from scratch. On a previous install I had some issues with missing EPG data from the Freesat EPG after a while, which is why I re-started from scratch with a new install running with the Sky EPG (This main TV Headend recording server is running on a Debian OS with OpenMediaVault on an cheap Celeron x86 box with an 8TB USB 3 hard drive connected. However I also have a pair of Pi 4s running Raspberry Pi OS that are able to use other tuners on the same DVB-T/T2 and S/S2 network tuners - and both are running fine).

    I use the BSkyB Bouquet 5 - HD England : London to allocate logical/local channel numbers from the Sky EPG.

    I only have the PSB3 mux in my set-up for Freeview (I sometimes want to record both Freeview HD and Freesat HD variants of the same broadcast) currently - and the EPG source entries for that, like yours, are blank.

    I've manually renumbered the Freeview HD channel numbers to the 1xxx range and renamed them to have DVB-T2 in their titles so I can explicitly schedule DVB-T2 recordings.

    I have no obviously missing EPG data - though I used to suffer from missing channel listings data occasionally (usually when they had changed transponder)

  • LibreElec Rpi4 TVHat TVHeadend - Recording Problems

    Quote from boragthung

    I was not totally sure of the precedence of collector that should be set to keep the latest epg and if one will totally overwrite the information collected by another or just update it? If you understand what I mean? So if I have collected the 7 day epg with Freesat, then a later run collects it with Open Sky, does that Sky collection totally overwrite the Freesat collection or just fill in the gaps? I only have the Sky one enabled as well as the Freesat as I find info from some channels will be missing without it.

    I've wondered about this as sometimes I get series/episode info in the TVH gui then at a later point I don't so I have suspected if one collector has this info it could be being overwritten by the one that doesn't.

    I would only run Sky or Freesat EPG collectors - not both - or if you do have both - chose one EPG source per channel.

  • LibreElec Rpi4 TVHat TVHeadend - Recording Problems


    You misunderstand me - I use the accurate recording option of 'Use EPG Running State' in the Recording Config - which uses the triggers for Rec start and stop in the EITpf DVB data.

    I have used TV Headend for 10+ years and never touched the cron settings - they're all on the defaults. The defaults have always downloaded the Freeview/Freeview HD and Freesat or Sky EPGs OK for me - though I've not got recordings regularly set for shows that are likely to be disrupted by sport (like the BBC Ten O'Clock News for instance)

    Wimbledon is going to be an issue as shows switch channel and the EPG EITpf stuff doesn't cope with that (Freeview+ and Sky+ also struggle with channel switches for the same reason) I think that's a known issue. AutoRecs might work if the EPG is updated but I don't think you can run an EPG update every minute to catch those very last minute EPG changes (as opposed to EITpf changes) - but Wimbledon is a known issue.

    However football delays and overruns like the Eurovision Song Contest are often handled OK from memory.