Bug #5325
idle mux scan stuck at certain mux
0%
Description
See attached log file. Idle mux scanning gets stuck at a certain mux.
With patch behavior went away.
Files
History
Updated by Jaroslav Kysela almost 6 years ago
- Affected Versions Tvheadend-20 added
TAILQ_INSERT_SORTED_R should maintain the reversed sort (thus sort queue list from the largest to lowest).
The condition 'if(cmpfunc(elm,_tmp) >= 0) {' means 'compare the new value (elm) with the value from the list (reversed lookup) - if the value from the list is higher or equal, insert the new value after.
I need more analysis what you're trying to resolve. Your change does not look good.
Updated by Jaroslav Kysela almost 6 years ago
- Affected Versions 4.4 added
- Affected Versions deleted (
Tvheadend-20)
Updated by Sebastian K. almost 6 years ago
May be it's to late but I think condition should be reversed...
if(cmpfunc(elm,_tmp) <= 0) {
same meaning if(cmpfunc(_tmp, elm) >= 0) {
in generel elm (a->mm_start_monoclock
) will be greater than _tmp (b->mm_start_monoclock
)
so in mm_cmp (b->mm_start_monoclock - a->mm_start_monoclock
) will be negativ
so should put it to end of queue (TAILQ_INSERT_AFTER
)?
Updated by Jaroslav Kysela almost 6 years ago
Nope, the array should be reverse sorted: 9,8,7,6 etc. If you add new item, there is reverse loop (6,7,8,9 array items) and 'if (new_item is smaller or equal then item_from_array) then place_new_item_after_the_item_from_array '.
So, we should find where the culprit is. It's probably in mm_cmp(). The weight is probably similar for most cases, so the clock comparison comes to play. Because the last touched (started) mux will have the monoclock timestamp higher, it will be placed to the start of the reverse sorted array. It might make sense for the normal scan (when the scan process is interrupted), but not for the idle scan (where the mux should be re-added to the end of the queue). I need to think more about this.
Updated by Sebastian K. almost 6 years ago
This was my first approach and this will also work fine for this special use case (idle scan)… but looks also ugly to me... and I don’t know what code parts would rely on this behave.
--- ./tvheadend-git/src/input/mpegts/mpegts_network_scan.c 2018-11-15 11:09:05.772310878 +0100 +++ ./tvheadend-git.mod/src/input/mpegts/mpegts_network_scan.c 2018-11-10 18:53:36.112286988 +0100 @@ -36,7 +36,7 @@ { int r = b->mm_scan_weight - a->mm_scan_weight; if (r == 0) { - int64_t l = b->mm_start_monoclock - a->mm_start_monoclock; + int64_t l = a->mm_start_monoclock - b->mm_start_monoclock; if (l == 0) return mpegts_mux_compare(a, b); r = l > 0 ? 1 : -1;
if I’m right tvh cmp functions (mm_cmp, mpegts_mux_compare) will return a positive value if a is lower and negative if higher?
uuid_cmp on the other hand will behave “normal”. Negative if a is lower and positive if higher.