Summary
When ViniPlay is served over HTTPS (e.g. behind a reverse proxy with TLS), live-channel logos fail to load and every channel shows a ? placeholder. VOD posters work fine. The cause is that live-channel tvg-logo images are referenced directly by their provider URL, which is almost always plain http://, so the browser blocks them as mixed content on an HTTPS page.
Environment
ViniPlay v0.11.0 (latest release), Docker image ardovini/viniplay:0.11.0
App reached over https://… (reverse proxy terminates TLS)
Default redirect stream profile; provider is Xtream Codes style
Example tvg-logo value from the generated live_channels.m3u: http:///images/1282703.png
Steps to reproduce
Load an M3U/Xtream source whose tvg-logo URLs are http://.
Access ViniPlay over https://.
Open the channel list.
Expected: channel logos render.
Actual: all channel logos show the ? placeholder; browser console shows mixed-content blocked image requests to the http:// logo URLs.
Root cause / suggested fix
VOD posters are already routed through GET /api/image-proxy?url=…, whose own comment states it exists "to avoid mixed content warnings" and it accepts any HTTP/HTTPS URL (with disk caching). Live-channel logos are not routed through it — they're rendered directly from the raw tvg-logo URL.
Suggested fix: render live-channel logos via the existing /api/image-proxy endpoint (same as VOD posters), so the browser only requests same-origin HTTPS images. This reuses existing code and needs no new endpoint or setting.
Workaround
None that's durable — editing tvg-logo in live_channels.m3u by hand is overwritten on the next source refresh.
Summary
When ViniPlay is served over HTTPS (e.g. behind a reverse proxy with TLS), live-channel logos fail to load and every channel shows a ? placeholder. VOD posters work fine. The cause is that live-channel tvg-logo images are referenced directly by their provider URL, which is almost always plain http://, so the browser blocks them as mixed content on an HTTPS page.
Environment
ViniPlay v0.11.0 (latest release), Docker image ardovini/viniplay:0.11.0
App reached over https://… (reverse proxy terminates TLS)
Default redirect stream profile; provider is Xtream Codes style
Example tvg-logo value from the generated live_channels.m3u: http:///images/1282703.png
Steps to reproduce
Load an M3U/Xtream source whose tvg-logo URLs are http://.
Access ViniPlay over https://.
Open the channel list.
Expected: channel logos render.
Actual: all channel logos show the ? placeholder; browser console shows mixed-content blocked image requests to the http:// logo URLs.
Root cause / suggested fix
VOD posters are already routed through GET /api/image-proxy?url=…, whose own comment states it exists "to avoid mixed content warnings" and it accepts any HTTP/HTTPS URL (with disk caching). Live-channel logos are not routed through it — they're rendered directly from the raw tvg-logo URL.
Suggested fix: render live-channel logos via the existing /api/image-proxy endpoint (same as VOD posters), so the browser only requests same-origin HTTPS images. This reuses existing code and needs no new endpoint or setting.
Workaround
None that's durable — editing tvg-logo in live_channels.m3u by hand is overwritten on the next source refresh.