Using docker version of ETV on unRaid. Version 0.8.7-a0a047ba-docker-nvidia
I'm getting numerous repeating messages that have this warning. Anything I can fix to address this?
#Multiple warnings: Ignoring ETV_CONFIG_FOLDER /config and using default /root/.local/
short gorge
silver nova
After a power outage I had to set up all my channels again because all my settings were lost.
So in hope to prevent this in the future I mounted the config to:
- './config:/root/.local/share/ersatztv'
But now I'm getting the same error in the logs:
WARNING: Ignoring ETV_CONFIG_FOLDER /config and using default /root/.local/share/ersatztv
Folders and all files were successfully created, but ETV doesnt seem to use them
crimson plover
hmm. that message is only supposed to display once at startup, to let you know that etv's default config folder in docker has moved from /root/.local/share/ersatztv to /config, but it should work in either case and it shouldn't spam those messages
short gorge
The error on my end displays every few seconds, bloating my logs. Other than that, etv seems to be functioning fine. Well, I do have playback issues on HLS Direct for random movies, but I need to dive into that a little more before asking for help on that.
cedar isle
"HLS Direct" only takes your original file and splits it into segments, no transcoding/conversion is happening.
So if you have issues with "HLS Direct", the usual cause is the software/app/device that plays back your content.
Be aware that there are inherent issues with "HLS Direct" when you mix & match files with different video or audio codecs, different resolutions, different framerates etc.
Simply put, most video players don't really like it when the "video stream" parameters (codec, framerate etc.) change mid-playback.
That is an inherent "issue" (I put it in quotes simply because it shouldn't really be happening) with how video playback works.
There are some players/software that don't mind it, to an extent, but it's usually not the norm
short gorge
Thanks for that explanation@cedar isle
I’m using a fire tv cube (3rd gen) for playback of HLS Direct. Is this different then how, say, Emby does it? I play movies on the same device via Emby and no transcoding takes place.
cedar isle
When a video player like Emby or anything similar plays video files, then it re-initializes the playback context every time a new file is being played (ie: playback starts)
Because video doesn't really change mid-playback. IE: you're playing a 1080p (full hd) h264 video, at 25 fps from start to finish
So when the player starts playback, it knows what context to initialize, either in software or directly in hardware, it knows to expect the same video parameters for the whole playback until it ends. If using hardware acceleration, it initializes specific function in that hardware to play back a specific type of video with specific parameters.
...now, for the purpose of "video streaming", the whole playback session is meant to look like a single "file" (broadcast) from start to finish
(or from midway to finish... where finish is you stopping the video or the transmission ending, that's not important)
Now, because of this, most hardware will have a fit about you changing the video type/parameters mid-way, because they weren't designed with such thing in mind
ie: if you have Episode 1 in h264 30fps, but then you have Episode 2 in hevc 25 fps, the video type changes mid-way and your hardware decoder will tell you to fuck off, as it doesn't know what to do with the suddenly changed data
short gorge
That makes a lot of sense.
spice rune
I get the same log spam, but not running into any issues
I’m not specifying those env variables in my deployment either if that matters
just mounting the default directories elsewhere
spice rune
I was still getting this spam, but changing it to the new top-level dirs as mentioned made it stop. I'll just use/advise those from now on