Posts by noggin

    Okay will do, thanks again. A bit of a medical hiccup today, I'll try to do all that this week some time.
    I can't understand why it's needed though, as the first time I set it all up with the first pc-based box the auto scan worked fine and did so right up until the box failed. Then just over a week later when this pi box was setup the frequencies had all changed coincidentally in that week? Seems unlikely.

    No - but in this situation it's likely that your PC box would have been updated automatically with the new frequencies when the stations moved - that's part of the DVB spec that TV Headend follows. In other words, the frequencies from the set-up wizard were correct when you set-up TV Headend, the updated frequencies were sent in an updated network information table (I think it's NIT that does this) over-the-air that is part of the DVB spec. TV Headend saw the updated table, automatically added the new muxes and then scanned them, providing continuity of service. (DVB has this as part of its spec so you don't need to re-tune your TV if there are transmission / frequency changes)

    When your box failed it was likely using the new frequencies - you just won't have been aware it had effectively re-tuned in the background to cope with the changeover - and just assumed it was using the frequencies originally added at set-up.

    However at the moment the frequency database that TV Headend uses is out of date - so when you start a clean install now it doesn't know about the new frequencies in use in your area, it uses the old ones (as your original install did) but now it can't tune to any services, so can't do what your old install did (as it can't receive a NIT from any service).

    As explained - add the muxes manually. You may only need to add one and network discovery will automatically add the rest.

    We're not doing this to waste your time - we're trying to help.

    I've been using TV Headend in the UK, Germany, Sweden, France, Finland, Estonia, Denmark and the Netherlands etc. for a long time - I've always ended up starting with manual muxes and local transmitter frequencies as it's just the way that is guaranteed to work (assuming you've got a set-up with the right drivers and an aerial/antenna feed with a signal on it...). I set up new installs all the time. I never use the wizard for tuning - I always start from scratch so I know what I'm doing. It also makes troubleshooting a lot easier as you've given things sensible names.

    You're still using the pre-defined muxes in the set-up wizard. They're out of date. Don't use this method for set-up.

    You need to add your muxes manually as I explained previously.

    I always bail out of the set-up wizard after setting English as my language, and then take over manually. (Keeping the frequency tables up to date for every country around the world has not been something the small number of TV Headend devs have been able to do - and users aren't updating it with pull requests to github either)

    Because you've got a tonne of rogue stuff in your networks and muxes tables I'd start from scratch or at least delete the stuff you've already added. (You added repeat networks which is why your network and mux view is so busy)

    In the configuration-DVB inputs-network tab delete all the networks that are currently there, and add a new DVB-T network (This 'network' is a TV platform - nothing to do with computer network). You want to create a new DVB-T network with a name of your chosing - e.g. OTA, Terrestrial, Freeview etc. You don't need a different network for ABC, Seven, Ten, Nine etc.

    In the configuration-DVB inputs-muxes tab if there are still existing muxes then delete them (though deleting the networks should have deleted the muxes associated with them) and add new ones with the right frequencies to the network you created in the steb above. (The post I made earlier has the current frequencies for the area you live in I think - they're different to the ones you are adding automatically with the out of date channel list the set-up is using).

    Note that you need to use the frequency in Hz - so ABC on 620.5MHz = 620500000. You need to select delivery system as DVB-T, and probably need to select bandwidth as 7MHz. You may also need to set constellation as QAM/64, Transmision Mode as 8k, and possibly Guard Interval as 1/16 (I've NEVER had to set Guard Interval manually) - though often leaving everything but delivery system, frequency and bandwidth to Auto works fine with most tuners

    In the configuration-DVB inputs-TV adaptors tab - add your network to your DVB adaptor and enable it.

    Select your network in configuration-DVB inputs-network and click 'Force Scan' to force it to tune the frequencies/muxes you've manually added. (It may already be scanning - but it doesn't help to kick it into doing it)

    In the configuration-DVB inputs-muxes tab you'll see whether it's OK (tuned and found services) or Failed (Pending means it hasn't tuned yet)

    In the configuration-DVB inputs-services tab you'll see the tuned TV channels. Click 'Map services' to map them to the Logical Chanel Number that Australia uses for each channel (i.e. the channel numbers everyone in Aus uses - ABC on 2, SBS on 3, Ten on 1, Nine on 9 etc.). In Kodi you'll also need to enable using channel numbers in the Live TV Settings in Kodi System settings - if you want standard channel numbers in Kodi.

    Quote

    So you mean I just can't use my uSD card directly using Imager and I need to prepare the card first, to flash it via gparted in FAT 32 ? But do I need to make different partitions in FAT 32 on the sd card ?

    No - I mean that you said you hadn't flashed it. Raspberry Pi imager and Balena Etcher both flash micro SD cards - I was trying to clarify what you had done if you hadn't flashed it. Flashing = writing the img.gz file to the uSD card using an imager program. If you used Pi Imager and manually selected the downloaded img.gz file with no customisation you've done the same thing as me.

    Quote

    I din't try any other uSD card because I really didn't have a clue it could work with a software and not working with another one. And I don't have any other uSD card. Is there one size and constructor that is better ? So I can buy one to see if it works best.

    uSD cards can fail in many ways - it's just a normal troubleshooting step. There are very few things that can go wrong - but the uSD card is one of them.

    I always use Samsung EVO cards - seldom had an issue with them. As for size - it depends what you want to store on the uSD card. If your media is on external drives and you just want to keep your library on your uSD card - then 32GB or 64GB is probably fine. I buy the 64GB and 128GB these days in the Pis I still use uSD cards with (I've got Pi 5s running NVME SSDs on M.2 hats)

    Using linux without beeing a geek, it's too complicate for me to install balenaEtcher since they don't have a .deb file for it.

    Do you only have Linux computers?

    Ah - those types of installers aren't recommended these days ISTR - which is why NOOBs was deprecated.

    What do you mean by "I didn't flashed my sd card because one told me the IMAGER do all that needs to be done. Maybe it's wrong and I need to format and make partitions ? I don't think the failure comes from the uSD card since I can install LE through PINN."

    How have you flashed the .img.gz image to your uSD card? Flashing doesn't mean doing it manually - it just means taking the .img.gz file and copying it in a certain way to your uSD card - which is referred to as flashing or burning (the media used to be called Flash ROM)

    You have to flash/burn/write to the uSD card - whether you use Pi imager or Balena Etcher or Rufus etc. - those applications are designed to flash the card in the way that will allow the Pi to boot correctly from it.

    What you can't do is just copy the .img.gz to the uSD card - it needs to be flashed.

    How many uSD cards have you tried? You can find that failing uSD cards work in some ways and not in others.

    Personally I'd install Balena Etcher and try that as it's simpler than Pi Imager, though I've just got my Pi 3B+ working fine using Pi Imager and that LE-hosted img.gz file... I'd also try a different uSD card.

    I'm assuming your HDMI display is a normal one capable of 1080p60, 1080p50 etc.?

    Thanks for helping a newbie like me ! I downloaded this one LibreELEC-RPi2.arm-9.2.6.img.gz

    I will try the one you told me. I'll do that right now and let you know right away.

    Thanks again !


    Unfortunately like all my tries, nothing happens when I start the rasberry pi. Even if I plug out and in again it doesn't start...

    It works with PINN that I installed and reinstalled a few times now so I don't understand what the problem can be with the old version of LE.

    I don't know anything about PINN I'm afraid - I only use Raspberry Pi OS, Ubuntu, OpenWRT and LibreElec on my Raspberry Pis.

    How are you flashing your uSD card - and have you tried more than one to rule out a failed uSD card (that can happen)?

    You definitely have a Pi 3B+?

    What is your display you are connected to via HDMI?

    Do you see the rainbow Pi screen?


    I'll see if I can dig out a 3A or 3B and give it a go with that image to double check.

    ** EDIT **

    Just downloaded the image above, flashed it to my uSD card using the latest Mac version of Raspberry Pi imager.

    I selected Raspberry Pi 3, as my device, chose my LibreELEC-RPi2.arm-9.2.8.img.gz file using the custom.img option in the Operating System drop down, my uSD card in the Storage System - and no customisation when prompted.

    I then plugged that uSD card into a Raspberry Pi 3B and powered up. I got the standard Raspberry Pi rainbow screen, then a LibreElec splash screen, then the resizing file system stuff, then it rebooted into LibreElec and the Welcome set-up wizard.

    So either you have a problem with your uSD card, how you are flashing your uSD card or how you are looking at the output of your Pi.


    Personally I'd try BalenaEtcher for flashing your uSD - it's much simpler to use and it does a verify after flashing.


    Can also confirm it plays 1080p25 HEVC/h.265 Main 10 files at 5Mbs with 50% CPU on all cores and no major frame drops (just a couple of skips at the start), but 12Mbs stuff is too much for it.

    Hi !

    Sorry for the late reply but hard to find time to do it. I downloaded the file that MatteN told me from this page https://ftp.halifax.rwth-aachen.de/libreelec/ wrote it on the sd card with RPI Imager but once again the rasberry pi is not starting on it... :(

    Do I need to do something with the sd card before writing the LibreElec image on it ?


    Thanks for helping !

    It would help if you told us precisely which image you downloaded - there are a lot there.

    You need the img.gz file to flash to an SD card. I use BalenaEtcher but RPi Imager should also work.

    Out of interest why aren't you downloading from the LE site here : https://libreelec.tv/downloads/raspberry/

    If you scroll down you can find : https://releases.libreelec.tv/LibreELEC-RPi2.arm-9.2.8.img.gz which is the Raspberry Pi 3 LE 9.2.8 release that I think you want to use?

    chewitt advised that 9.2.8 is the last build with the legacy support for the hardware accelerated HEVC decode on the Pi 3 series. (That's why LE are still hosting it)

    What about RGB vs YCbCr (aka 4:4:4/4:2:2/4:2:0?)


    Some info from here:

    So RGB - is there a way to force 4:2:2 ? (I realise this will only work at 30Hz refresh and below on 2160p resolutions without a high-bandwidth 'Enhanced' HDMI path and destination)


    It can't be as simple as LG interpreting RGB=PC and YCbCr=Video can it?

    Back to square one.

    It seems that after every start of LE and LG TV, HDMI4 input is reset to PC.

    After changing the icon of the HDMI4 port on the LG TV, or even change one character of the name of the HDMI4 port, the desired settings are available again. I don't have this issue with the set-top box of my Dutch ISP provider KPN connected to HDMI3.

    So is it some kind of miscommunication between LE and LG TV? Who can tell...

    This couldn't be as simple as RGB = PC, 4:2:2 YCbCr = Video could it? (Or infoframes flagging 0-255 = PC, 16-235 = Video levels?)

    Is there a command line command you can run on a Pi 4B to report the HDMI output format being used - that might help add some information?

    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.

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

    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)

    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.

    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?

    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.

    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?

    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.