When accessing on-line streams with a WebResource, the first successful access of a stream will cache the streams characteristics. This includes the DAR of the stream which Serviio subsequently checks when a profile includes "DAR=16:9".

If the characteristics of the stream subsequently change (as they do on sites that stream different TV channels under the same stream url as new sports events occur), Serviio will continue to generate a -vf pad= based on the original cached parameters and the result will be incorrect.

It seems there are 3 options:1. Use a cache key which includes a timestamp so that the stream parameters are checked and re-cached with every refresh. My concern is that the cache size will grow excessively. It also means all refreshes will take a long time. Do old cache entries expire and get removed at some point?2. Set a manual switch eg: a file that I can read when the web resource is executed at refresh time, and append that files content to the cache key to cause a re-cache.This would allow a re-cache on demand, and minimize the number of cache entries, but is kludgy.3. Ask that Serviio be changed so that a "Force refresh" of an on-line feed will cause the feed to be re-cached. This would be consistent with the current re-caching of the feed items on "Force refresh". Extending this thinking, the images should also be refreshed to reflect any changes because the feed item images can change over time. These changes would then make "Force refresh" act the same as when a new feed is added to Serviio.

zip wrote:How often did you encounter the changing DAR? It feels it should not happen that often.

True..only on those sites that offer channels of events, where each event on a channel may use a different streamer with different streaming characteristics. Also its not only the DAR but if the PAR (width/height) changes the padding will also be wrong.

The real issue is the inability to reset the information that Serviio caches when a new stream is accessed. Right now Serviio remembers the initial data forever and there is no ability to update it without wiping out the database and rebuilding it, or by using a different cache-key on every refresh which would grow the database and use excessive cpu to run ffmpeg on every feed item on every refresh. Seems to me refreshing that info on a "Force refresh" would be appropriate. Same with the image which can now only be changed by erasing the thumbnails cache.

I have a plugin for a site that offers a set of channels which have not changed in months.

When first cached the streams were 0:0 = Data 0:1 = Video and 0:2 = Audio and Serviio transcoded them with -map 0:1 -map 0:2

I now find those streams no longer play because they are now 0:0 = Video and 0:1 = Audio and Serviio still transcodes them with -map 0:1 -map 0:2 which generates the error "Stream map '0:2' matches no streams."

The only way to fix this is to rebuild the whole database, or add a date stamp to the cachekey and rebuild with every refresh which would be silly.Rebuilding with a "Forced refresh" would be an appropriate solution. Are you agreeable to a request for that?

But wouldn't it be better for users to have their feeds refreshed via an expiry time (I don't remember if expiresOn refreshes the tech metadata?). As when they see an error, they will not necessary know that clicking ion Force refresh could help it. If you had it expire every day, at least they would come the next day and the streams would magically work again.

PetrServiio developer / site adminDo not send me PM for support as the solution can't be shared with others.