Sat Feb 01, 2025 12:15 am
Transcoded movies and concurrent MediaBrowser sessions
I have a problem with transcoded movies and concurrent MediaBrowser sessions from the same IPv4 address. It seems that an existing transcode folder gets removed as soon as someone else from the same IPv4 address starts another movie. That is, regardless of the ID of the MediaBrowser session. As a result, the video stream for the earlier client stalls because its transcode folder no longer exists.
It took me quite some time to find out what is going on, and the only other reference to a similar problem that I found is from 2012:
https://serviio.org/forum/viewtopic.php?t=8000#p56260
From what I observed, the logic described in the last post of that thread still seems to be in place.
Now let me describe my setup, and why this unfortunately is a show stopper for me. I modified the "HTML5" and "HTML5 Mobile" profiles in "application-profiles.xml" in a way that they transcode everything, because for not transcoded movies the audio track selection in MediaBrowser does not work. Well, no big deal because this most of the time means only remuxing, which is easy on the CPU and needs just some disk space.
In addition, clients using MediaBrowser access my media server via a reverse proxy (Apache with the standard recommended proxy setup as per the Wiki), which works really well because this way I can use the Let's Encrypt SSL cert I have for that web server already. And I can even access the media server by IPv6, even though Serviio itself is IPv4 only, as far as I can tell.
Now guess from which IPv4 address in this scenario all the proxied connections come from Serviio's perspective, and what this then does to the transcode folders in case of concurrent client sessions. I tell you: The connections all come from that single proxy server IP address, and therefore each of the client sessions wreaks havoc on all of the other clients' transcode folders.
Provided that my observations and diagnosis are correct, isn't relying solely on the client's IP address with regard to the transcode folder garbage collection a little too simplistic for remote access? This approach would even break without a reverse proxy in front of Serviio. What if two or more persons in the same household, behind a common home router, would like to watch movies via MediaBrowser? The home router would NAT all their internal LAN IPv4 addresses to the router's single IPv4 address. So no fun with transcoded movies there either.
Therefore, in case of access via the API that MediaBrowser uses, wouldn't it make more sense to use the session ID in order to decide which transcode folder can be removed? This should be proxy and NAT proof. Of course, since I do not have access to Serviio's sources I cannot tell whether this approach would be feasible, or whether things would perhaps turn out to be more complicated in practice. I guess only Serviio's developer, Petr, can tell.
I am currently at a loss of how to mitigate the problem with the means I have at my disposal. I could get rid of the reverse proxy, but, as I described, things would still break with multiple MediaBrowser clients behind a common home router. I actually do have these cases among my Serviio users.
Best regards,
Uwe
It took me quite some time to find out what is going on, and the only other reference to a similar problem that I found is from 2012:
https://serviio.org/forum/viewtopic.php?t=8000#p56260
From what I observed, the logic described in the last post of that thread still seems to be in place.
Now let me describe my setup, and why this unfortunately is a show stopper for me. I modified the "HTML5" and "HTML5 Mobile" profiles in "application-profiles.xml" in a way that they transcode everything, because for not transcoded movies the audio track selection in MediaBrowser does not work. Well, no big deal because this most of the time means only remuxing, which is easy on the CPU and needs just some disk space.
In addition, clients using MediaBrowser access my media server via a reverse proxy (Apache with the standard recommended proxy setup as per the Wiki), which works really well because this way I can use the Let's Encrypt SSL cert I have for that web server already. And I can even access the media server by IPv6, even though Serviio itself is IPv4 only, as far as I can tell.
Now guess from which IPv4 address in this scenario all the proxied connections come from Serviio's perspective, and what this then does to the transcode folders in case of concurrent client sessions. I tell you: The connections all come from that single proxy server IP address, and therefore each of the client sessions wreaks havoc on all of the other clients' transcode folders.
Provided that my observations and diagnosis are correct, isn't relying solely on the client's IP address with regard to the transcode folder garbage collection a little too simplistic for remote access? This approach would even break without a reverse proxy in front of Serviio. What if two or more persons in the same household, behind a common home router, would like to watch movies via MediaBrowser? The home router would NAT all their internal LAN IPv4 addresses to the router's single IPv4 address. So no fun with transcoded movies there either.
Therefore, in case of access via the API that MediaBrowser uses, wouldn't it make more sense to use the session ID in order to decide which transcode folder can be removed? This should be proxy and NAT proof. Of course, since I do not have access to Serviio's sources I cannot tell whether this approach would be feasible, or whether things would perhaps turn out to be more complicated in practice. I guess only Serviio's developer, Petr, can tell.
I am currently at a loss of how to mitigate the problem with the means I have at my disposal. I could get rid of the reverse proxy, but, as I described, things would still break with multiple MediaBrowser clients behind a common home router. I actually do have these cases among my Serviio users.
Best regards,
Uwe