…tion from Antonio Marcos Lopez Alonso Thank you Antonio! Closes #12086 Signed-off-by: Nicolas Riendeau <firstname.lastname@example.org>
This function appears to be unused as of now, but it came up in the new unit test.
When seeking repeatedly close to the end of the program in liveTV, it would cause playback to jump immediately to the next program. The cause was RingBuffer:: IsNearEnd didn’t report if we were close to the end of the file, but if there was little left to read in the ringbuffer. However, when seeking the buffer can be emptied, causing IsNearEnd to always return true Additionally, with very low bitrate stream (like with the HLS recorder), we could sometimes miss over significant length of video. A positive side effect is that there’s now no pause whatsoever between two liveTV program,s at worse about 20 frames dropped. Ref #12076
If file is already opened, no need to use QFileInfo
From the ticket: Not sure why it was comparing the first char of both strings, also think it shouldn't be case sensitive at all. I think so, too Fixes #11088 Patch by Daniel Ribeiro
When watching a recording from liveTV group, player_ctx->recorder is null. There’s also no card id to record. Fixes #12079
…layback to start faster.
…ardware to transcode to 720p in realtime. Until we can figure out a way to disable it selectively on systems that can't handle it, it's better not to even offer it as a choice.
…hould endevour to use the lowest possible profile and baseline allowed by the chosen resolution and bitrate to support the widest variety of playback devices.
…sure which of the two is authoritative but might as well go with the one which allows smoother streaming.
…s actually already done at the transcoder end, it seems HTTPLiveStream also needed telling to label the streams correctly.
…re the speed gain, but quality isn't significantly degraded.
…means the buffer size may be incorrect.
…of time and will only degrade quality. Since the end client can't know the original resolution of the video it can only request the ideal e.g. 1280x720. So for SD videos we don't alter the resolution and for Full HD we scale down. Ultimately we may scale the bitrate accordingly, but for now it remains unaffected.
…(Mobile) or 720p (WiFi). 360p is the default unless the client IP is local, in which case we use 720p instead. The chosen bitrates are based on Apple best practice guidelines for HLS.
Recalculate the threshold and read block size when we've encountered EOF several times in a row. 512kB ought to be enough to read a file smoothly (famous last words) This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read. Refs #10428
This reverts commit 43cba65.
Also increase the threshold at which we increase the read block size. 512kB ought to be enough to read a file smoothly (famous last words) This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read. Refs #10428
Seeking across liveTV was fundamentally broken. You could only seek within the current recordings or go to the beginning of the next one or 15s to the end of the previous one. This changes correct this behaviour. It is now possible to seek across the entire live TV session. We ensure however that we do not seek further than 15s from the end of a recordings (3s if reaching end of live program). Fixes #12076
The values are moved to the default recording rule template in schema change 1302, see [71c65ba]. These old values have been confusing users of MythWeb for long enough.
Move the use of settings from the RecordingRule constructor to the schema update that creates the default, recording rule template. The settings are removed from the database in a later schema update.
Previously, if any tuner in the same input group was already busy, preroll would not be applied. Now, if the recording on the other input is on the same multiplex as the new recording, preroll will be applied. Fixes #12023
…ause they are apparently not compatible. They build, so let them.