I’d say if you were a little clearer on your physical hardware setup and how you have your setup configured you might get a more positive response, otherwise you’ll get the stock response , please supply logs. It may well be that it is not even an LE issue.
Posts by petediscrete
-
-
I’m just guessing here but sounds like your client is not connecting with your server hence the PVR Manager starting message and then nothing. Check that the lan address configured on the client matches that on the server.
-
Attached is v0.0.3 using the TVH43 Alpha addon as the default 'server'.
Logging is currently fairly verbose. If you try it and something goes wrong, please send me your Kodi log. Actually, if you try it and it works, I'd also like to see your Kodi log just to see what the addon actually did on your system.
As soon as I get back from a business trip I’ll try it and report back.
-
As mentioned above I’d be willing to give it a try with TVHeadend43 Alpha or whatever the hell it’s called these days. Zero point going backwards now.
-
Just be advised that the moment there's upstream movement on a TVH 4.4 release we will be dropping the TVH 4.2 add-on (as 4.2 will no longer be the 'stable' TVH release). It would be better to develop against the 4.3 add-on.
That’s interesting. Could you elaborate a little more on that. I didn’t notice any mention of that on either the TVH forum or Github.
-
You don’t mention what PVR server/client you use. Try give a little more detail on your current setup.
-
Yes that checks out with the last available arm update on the 20231209. I assume once you switch over to aarch the LE updater is back functional again which speeds up the nightly update process.
I work on the basis of “if it ain’t broke don’t fix it” so I’ll stick with the arm install I have for the moment. I don’t want to tempt fate at this stage 😝
The Rock64 is an excellent SBC but unfortunately support for it is marginal to say the least. It was sitting on the shelf just waiting for LE to be installed and I’ve had zero issues with it since. I’ll probably start with a fresh aarch install on a separate SD card and take it from there. Would an arm backup restore successfully on an aarch install I wonder.
-
I found the inbuilt LE updater very convenient as I didn’t need to find a unit to remotely access LE to run an update every night. I’m happy enough to stay on the arm 20231209 version at the moment.
What does surprise me is I haven’t noticed anyone else highlighting this issue before now. In fairness I don’t spend much time on the forum. I prefer to enjoy the LE experience instead and updating nightly and testing each release was my contribution to the project. Thanks anyway.
-
yea something is broken with all 3328 builds, they are build correctly but never arrived at the nightlies, we have a look
Ok. I’ll hold off using the nightly updates until the problem is resolved.
As I mentioned the LE check for available updates is still reporting the latest as 20231209 so it appears that it’s the last Arm version release that’s reported available on the server. The next available version after that is 20231210 but that appears to be an aarch64 build.
They are there it’s just the sort that is wrong. And arm versus aarch64.
Search for:LibreELEC-RK3328.aarch64-12.0-nightly-20240116-b7b2da0-rock64.img.gz (sha256)
Thought this was interesting. A little confusion over naming conventions.
Would that have any impact on the LE GUI updater not finding the latest nightly. -
Just wondering if the server is full. MY LE community nightly build version latest available is showing 20241209 yet the latest here is
-
Move the cursor to Connect Once and press return.
-
Check your logs for a definitive answer. It’s all there to be seen.
-
If it has been lying around for a while chances it needs a firmware update. Try that first by downloading the latest version of LE and do a fresh image to the SD card. From there you can troubleshoot it further. Could be a number of problems involved like bad image, faulty SD card etc so rule all that out first.
-
You might find that you are running banned add-ons and you’ll find you’ll get neither support nor sympathy on this forum. You may want to check this list before proceeding any further
-
As I mentioned above my figures were not science and vary with different tuners, Sat/IP and PCIe tuner in my case
I imagine a more sensitive tuner may take longer to tune a mux, not sure, and the signal quality on the network would also play a part in it too.
You may have to put it out there and invite others to participate in these tests to get a broader picture of what’s going on here.
I’ll certainly try a full scan on both tuners I have and supply you with feedback when I get an opportunity to do so. -
On Astra 28.2 DVBS with 69 active muxes a scan taxes approximately 30 minutes. This is purely a back of the hand calculation.
Maybe supply a user defined field option where the user can supply a variable in seconds between 1 and 60 and let the user decide how long the muxes are scanned for. Not every tuner performs the same when it comes to scanning.
-
Yes - and you got an useless answer.
If you are referring to the fact that it was probably a Kodi issue why do you imagine that was a useless answer. The folks at TVH are not in a position to sort out Kodi issues. That’s for the team at the Kodi forum.
Tom_W Thanks for confirming the issue. As I wrote in the thread over at tvheadend.org, the web player of TVHeadend seems to allow to pause the stream and start again at the exact position, where I paused. Whereas in KODI, when I pause for a couple of minutes, the stream starts again at the real position, so nothing is cached. As I cannot test any other tvheadend client (TVHClient on Android doesn't support timeshift at all), I am not fully sure but, I would support your assumption that pvr.hts seems to handle TV and Radio differently regarding timeshifting. Maybe ksooo can help here?
You need to take the matter up with the PVR add on maintainer on their Github
Issues · kodi-pvr/pvr.htsKodi's Tvheadend HTSP client addon. Contribute to kodi-pvr/pvr.hts development by creating an account on GitHub.github.com -
There’s a whole ecosystem of expensive accessories built up around the RPI world. Since the original Pi I bought I never had one in a case nor ever needed fans or heat sinks.
At the price they retail for why end up paying double your outlay for a fancy case. A sheet of acrylic and four stainless coach bolts and nuts and you have a case that everyone will admire and is totally reusable no matter what model you own.I firmly believe the whole RPI accessories scene has become an obsession. At the price you pay for an RPI they are practically disposable items. Certainly not a medium to long term investment by any stretch of the imagination.
