That makes perfect sense! Now, about those logs... I have 50 GB of recording logs, many of the TVE logs are 60 MB with 100k lines each. Is there a log verbosity setting?
Do you have 800 recordings or is the logic to delete them when the recording is deleted not working?
1,845, but who's counting 
I suspect this is a new topic. Why don't you move this part to a library management topic.
I have a lot of programs that I intend to keep indefinitely, at least until I can figure out how to detect duplicates of Dateline and similar programs that are rereleased under different names.
How about a global log verbosity setting? "Error" level logging would have shown the looping error with only a few entries.
There are two kinds of data that we are logging in those logs.
One part is the HLS logs that you are referring to (that would have been enough for tracking down the issue with the looping).
The other part are the packet-by-packet logs that we have when rewriting the MPEG-TS streams to have consistent timestamps. Those are used less frequently, but are very important in being able to detect strange situations in TVE streams that could result in a corrupted stream.
We've decided to leave them on because we still occasionally run into situations where it is important for us to identify if there is an issue with our handling of the streams vs an actual corrupted stream coming from the source. Without this detail, we would just have to guess as to what the problem is, and would likely have to resort to assuming the issue is coming from the original source even though there's a small chance it is coming from us interpreting the stream badly.
The good news is that you could run rm Logs/recording/*/recording.log at any point and it wouldn't cause any issues with the running of the system.
We haven't run into cases where people were recording large numbers of recordings and were space-conscious, so it hasn't been a priority for us to do more to handle this, but you bringing it up does put it back on our radar.
Fair enough. I was also a bit concerned about the overhead of dozens of events per second being logged, but I'm probably applying 90's logic to the issue
We've profiled this code extensively and haven't found the logging to be something that is making an impact.
Of course! On the other hand, I was a bit worried that I had inadvertently enabled debugging-level logging and forgot that I did so...