Rick Gillyon

You need to map them in Plex settings in manage channels. So you need an epg source too. You can specify the epg XML file in the telly config, and tell Plex to use the telly epg at http://<telly IP>/epg.xml

Map /etc/telly to appdata/telly/ and put your m3u there. Reference the m3u in telly.congig.toml as M3U = "/etc/telly/xxxxx.m3u" If I was starting now I'd use the xTeve docker though.

I have a new(ish) Seagate 8TB IronWolf HDD in my server, precleared fine, but I'm seeing some SMART numbers that I don't get on my other drives, i.e. Raw read error rate 31460368 Seek error rate 49357490 G-sense error rate 2744 Hardware ECC recovered 31460368 The SMART extended test passes, and the hits I get searching for these counters are mixed: some sources (i.e. Wikipedia) say don't worry, the counter isn't a counter but some weird raw value; other sources (especially for read error rate) say that the drive is failing. I'm still in RMA period for this drive, so I'm really just looking for someone to pat me on the head and tell me it'll all be okay. Full SMART report attached. Thanks! ST8000VN0022-2EL112_ZA1FEFD2-20190807-1701.txt

Mylar stopped working properly for me sometime in April. Prior to that it worked like a champ, since then I've had maybe 5 downloads total. Logs attached, any ideas? Sab seems fine, Mylar has just stopped finding stuff, but can be found manually from my indexers no problem. Sonarr etc. still working fine with Sab. Thanks. UPDATE: For others getting this same issue, I've found a solution. Edit Mylar's config.ini and remove the provider_order line completely. Sometimes this gets screwed up. So far I'm back to working again. Funny that @CHBMB replied to this just as I was typing out the update...

I think this is an unrelated Plex issue. I sorted this by rolling Plex back to 1.14.1.5488-1-01

Thanks for that. I always assumed Prefer and Only would move.

It does not happen with a cache drive, mover will just do the initial move then it's there for good.

Just set your appdata share to use cache, then mover will move it.

Hit the Container Size button on the Docker page to see which Docker is the problem.

Still root. Look at chown and chgrp. Even better:

Plex is causing this. Roll back to a stable version.

You need to wait for Binhex to release an update. Unless you have a version label specified in your docker, e.g. binhex/arch-plexpass:1.14.1.5488-1-01 - then you need to change the tag to latest to get updates.

Monitoring memory, this seems to be a problem with recent versions of Plex eating up all available memory and grinding the system to a halt. Regressing Plex to an earlier more stable version seems to have fixed the problem (so far). Thanks for the help.

Thanks, I already did that, it's fixed my problem so far. 👏

Running the latest version on 6.7.0-rc5, Plex is constantly using over 40% of memory. That's over 6.5GB. Even when it's doing no recordings, plays or transcoding. Does this seem right or is there a problem? Edit: I've had my server maxing out CPU and memory and needing reboot every few days for the last few weeks, could this be caused by the new Plex version with the transcode problems?