Project

General

Profile

Bug #5325

idle mux scan stuck at certain mux

Added by Sebastian K. about 6 years ago. Updated about 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
-
Start date:
2018-11-11
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1529~gc8bbae504-dirty
Affected Versions:
4.4

Description

See attached log file. Idle mux scanning gets stuck at a certain mux.

With patch behavior went away.

Files

tvheadend.log (12.5 KB) tvheadend.log Sebastian K., 2018-11-11 00:24
patched_tvheadend.log (8.25 KB) patched_tvheadend.log Sebastian K., 2018-11-11 00:33
mod_tailq_insert_sorted_reverse.patch (498 Bytes) mod_tailq_insert_sorted_reverse.patch Sebastian K., 2018-11-11 00:33

History

#1

Updated by Jaroslav Kysela about 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.

#2

Updated by Jaroslav Kysela about 6 years ago

  • Affected Versions 4.4 added
  • Affected Versions deleted (Tvheadend-20)
#3

Updated by Sebastian K. about 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)?

#4

Updated by Jaroslav Kysela about 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.

#5

Updated by Sebastian K. about 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.

Also available in: Atom PDF