That’s why I wanted to see the contents of dmesg on that three step cycle. The stick doesn’t have an independent power supply so it’s likely that’s one of the sources of the problem.
If indeed it is the cause a power supply with a larger overhead would be a solution or failing that a tuner with its own power supply that’s proven to work. Another possibility would be a powered USB hub but again they come with their own problems too.
Run dmesg after boot. Then unplug the stick run it again. Finally plug it in and again run dmesg. Just post the relevant section of dmesg that relates to the stick.
So when you say “works in LibreElec and on PC/Ubuntu.“ can you successfully scan muxes and view them. What version of LibreELEC does it work in.
I’ve a feeling the lack of supported drivers in LE 11 on your RPI3 is the problem.
So far I've never lost anything - its just the inconvenience of disconnecting the HDD and hooking it up to a Windows PC for a repair. If I had the money (I don't) I'd be happy to have the house rewired and buy new kit & a NAS to run gigabit .
In my case its probably hundreds of hours - still a lot to repeat. I'd class myself as the first type of user but I operate with a restricted budget so only one backup.
Maybe you should decide exactly what you’re trying to achieve and take it from there.
As you didn’t indicate how you are running LE I’m assuming you’re a Windows user and reluctant to cut the chord. If that indeed is the case it’s been pointed out to you the dangers of mixing Windows and Linux file systems on a number of occasions. Who the hell wants to be constantly swapping in and out a HDD to repair it.
There are acres of discussions on the web about the pros and cons of each of the file systems and no definitive winner. What is obvious though is an HDD with an NTFS file system is not an ideal choice for LE.
One thing is for sure. LE is a Linux based OS and Linux based file systems are what you should be targeting.
Maybe get an identical HDD and format it Ext4 and copy the contents of your NTFS HDD to it and that takes all the wondering out of the equation.
Either way good luck with that setup. You did mention that you’ve lost no data so far but it sounds like that event could be closer than you think on your current trajectory.
Not unheard of but a possible faulty SD card reader. After you managed to boot from USB stick have you checked access to the SD card slot with an SD card inserted just for testing purposes.
What version of LE are you using. Just plug the RPI into a wired LAN and you’ll be back on line. That will allow you to enable the wireless LAN again.
What does lsusb and dmesg report in both LE and Ubuntu for the DAC. Is it correctly identified. Have you tried the DAC in Kodi for Windows. Does it perform correctly there.
Here’s an interesting article on that particular chip and it looks like the user got it to work eventually via SPDIF OUT https://discourse.osmc.tv/t/modifying-us…ect-spdif/78384
How are you using LE on the Dell. Is it installed on a USB stick.
As was mentioned before it’s best to keep Linux (and particularly LE) away from Windows file systems unless you want to spend your time repairing your file system. A UPS as mentioned above would certainly be an advantage if you are in an area prone to regular outages.
Personally I’d install one of the flavours of Linux alongside your Windows installation or even better install Linux on a second internal disk (SSD preferably) and install Kodi on that. From cold boot to Kodi screen is 3 seconds on a similar PC to your Dell. Better than some of the dedicated set top boxes out there.
Unless you have a particular need for LE, Kodi installed on one of the Linux flavours is the way to go with your Dell. Ubuntu or Debian would be my flavour of choice as I’m using it for years .
Yeah, thanks. The device actually works. Problem was I didn't know the exact symbol rates.
There are a ton of sources for firmware, not all identical, some broken.
I made it work with these
Code$ md5sum * d8da7ff67cd56cd8aa4e101aea45e052 dvb-demod-si2168-02.fw d643a75d2ced161bc5fb635aec694d9f dvb-demod-si2168-b40-01.fw 0c3f6bc5028bc37cfbf3a16d480bbaa5 dvb-usb-it9303-01.fw 9822ca23d24c46569ede9e07b1f13eee dvb-usb-terratec-htc-stick-drxk.fw
When you say you made it work with these, was that in LE or something else. The big problem is the different revisions of this stick. It is usually down to the Vendor ID reported not matching the actual installed on the chip.
Could you supply a little more detail on the cable service you are using and maybe someone here could supply you with the relevant S/R.
The biggest problem using DVB devices on LE directly is breakage on every kernel update. And that’s if you’re lucky enough to get the device working in the first place. That’s why I suggested using a separate RPI with the USB attached acting as a server, pin the kernel version on the server and you can do what you like with the LE client without worrying about breaking your server install.
Many of those USB sticks are hit and miss in Linux and many don’t even work no matter what firmware you throw at them. Again you can see from this list that your stick might be supported http://www.linux-hardware-guide.de/2012-11-02-ter…tc-usb-stick-hd
I really do advise that you install TVHeadend. You’ll have everything automated for you via the installation wizard and you can ask these questions on the TVHeadend forum as your problem isn’t actually LE related.
There’s a couple of different revisions of this USB stick and subsequently different Linux firmware versions. This Github provides a possible solution to the firmware issue https://github.com/brandsimon/deb…tec-cinergy-tc2
As I suggested previously, try getting it working on your RPI3 first using RPIOS on a different SD card before spending hours trying to get it working in LE. Reading from this 2018 post you’ll see what I mean
This link will give you the current situation with your USB stick https://wiki.archlinux.org/title/TerraTec…_MKII_USB_Stick
The perceived wisdom here is that you setup a separate server on another RPI using RPIOS and have it feed your LE client.
I understood TVHeadend cannot scan for muxes?
Is there a way to force scan for muxes?
I use the Terratec CINERGY TC2 USB Stick, but wasn't yet able to see any input. So not sure if it actually is working.
It can. Do you have one single known active mux from your cable supplier.
Did you try installing TVHeadend and using that to scan your muxes. What cable tuner are you using.
It’s quite simple to do a manual backup. Just drop the backup onto a USB stick and you’re good to go. In the event of a complete system failure and after a fresh install of LE just drop the backup file from the USB stick onto the newly installed LE and restore it.
I always do a backup just before a system upgrade and directly after it. Ensures there’s always something current to hand in an emergency. In fact I keep a spare SD card with LE installed close by. A simple swap out in the event of a failure ensures the evening’s viewing goes uninterrupted.
I don’t use the cloud (not my scene) but a 4TB drive more than adequately covers my storage needs.
It's hard to know what the issue is without seeing proper system or Kodi logs, but most likely something has gotten corrupted on the SD card. In that situation I'd recommend starting out with a clean install with LE11 (or an LE12 nightly) using a fresh SD card. This should get you back to a working (if not configured) system. From there you can connect the borked SD card using a USB > SD card adapter and see if the /storage partition on the card mounts to /mnt/<cardname>/storage or similar. If it does, restoring the general state of the previous setup is relatively simple and acheived by stopping Kodi, copying old userdata (database files, sources config and add-on settings) to the relevant location on the new card, starting Kodi up again, and (re)installing the add-ons that you were using. If you're familiar with some basic Linux fileystem and copy commands it's probably 5-10mins work to recover things. If you're not, it takes longer. If the old card fails to show up, then we need to see the system log to see what error messages are being generated. In that scenario it's probable that basic filesystem checks aren't going to get the card mounted and more complicated recovery processes might be required .. in which case "sorry, but now you understand the need for backups in the future!" is likely where we'll take a pause.
The mention in the OP would suggest that the user is not familiar with Linux hence my suggestion to install from fresh and find the last working backup. That’s why I didn’t suggest using any form of tools to carry out repairs on the file system. More trouble than it’s worth 😂
Satellite dish, IPTV or BBC Player.
Some might say it’s a blessing not to have BBC3 😂
