Rick Gillyon

This is quite the statement for a "mea culpa" thread, comes across as "sorry, but if you don't like it, GTFO." I *assume* that's not what you meant... 🙄

Same problem here in England.

I just grab the log from user scripts. As I say, it's not very helpful. You can also run the line in the console and grab the output. The problem will be SD returning crap data and causing g2g to fail, but unless they admit it we're stumped. Btw, you should change your grabber script to only overwrite your XML file if the new XML file is big enough. That way, even if it fails you'll have a week or so of data.

Currently SD say they have no problem and the error message: [ERROR] json: cannot unmarshal number into Go struct field SDSchedule.stationID of type string means nothing to them, not enough to go on. I've sent the full log. FWIW.

Raise a ticket with SD, when stuff like this happens they normally need to restart their services.

Not a clue, you'd have to try it for yourself.

I just have everything ticked. Nothing gets unticked when the docker restarts.

In Extra Parameters for the docker: --device /dev/dri:/dev/dri In go: #!/bin/bash # GPU modprobe i915 chmod -R 777 /dev/dri # Start the Management Utility /usr/local/sbin/emhttp & No idea VAAPI vs QuickSync, probably wasn't available when I set this up.

Dashboard will tell you if it's transcoding. Mine uses VAAPI hardware transcoding with an Intel chipset. You can also check if Premiere is enabled, just click "Emby Premiere" at the left of the dashboard.

Community Apps

xteve updates shortly after the xmltv job runs, and that clears the data. Is there some way I need to set up or could have broken caching? What samples would be needed?

The problem is that when downloading the xml, it downloads channels but no programme data, so it is a valid non-empty xml file, just with nothing useful. You think that's something I should raise with xteve?

A bit OT here, but I've changed my userscript that downloads xml from SD, so that it downloads to intermediate files and only overwrites the in-use xml if it's bigger than a minimum size: if [ -n "$(find "$fil" -prune -size +20000000c)" ]; then mv freenew.xml free.xml mv skynew.xml sky.xml outMsg="Success" else outMsg="SD BORKED" fi This way I don't lose my current data when SD breaks. This has happened twice in 10 days.

This is a red herring, the problem is with SD. The path will only be a problem if you don't make sure you're in the correct directory first.