Beta [webif] 1.4.9-7

Status
Not open for further replies.
Unfortunately I have suffered a crash with the new version similar to that reported with 1-4-9-6c after system had be running for about 1.5 hour.
At time of crash top was reporting humaxtv as using about 70% cpu and another process mtblockd (or similar) using 55%
Unfortunately crash occurred while I was attempting to take a screenshot so I am not sure of the details - i cant find any refs to a mtblockd on google

Before the crash I had noticed problems with detectads in chaserun mode - it was failing to obtain the DLNA helper and was therefore unable to decrypt the current recording. Will investigate further ....
 
mtdblockd - MTD (memory technology device) block daemon (or driver or device I guess). Turns flash storage into a something that looks like a disk device so you can put filesystems on it.
Maybe something is writing to flash constantly? Need to find out what though.
 
My devices (now 3 HDRs and 1 HD) are all operating normally, but then they're not doing anything much and certainly not chase decryption.
 
Has there been any change to the system dlnahelper function in this release?

It is now returning a null URL

Code in chaseget that was working until yesterday:
Code: 
        if {$url ne ""} {
                log "  $file - has been indexed."
                set helper 0
        } else {
                log "  $file - Not yet indexed, trying helper."
                if {[catch {
                    lassign [system dlnahelper [file normalize $ifile]] url
                    } msg]} {
                        log "  $ifile - $msg"
                        system dlnahelper -release
                }
                if {$url eq ""} {
                        log "  $file - Can't use helper. retry"
                        # system dlnahelper -release
                        if {$remain > 30} {sleep 15}  else {sleep 5}
                        continue
                }
                set helper 1
        }
If am now getting the Can't use helper message
 
That's as maybe, but why would it invoke mtdblockd? Or was that a red herring? If decrypt is blocked, why doesn't it fail gracefully?
 
MymsMan said:
Has there been any change to the system dlnahelper function in this release?
Click to expand...
Yes, well indirectly in system dlnaurl and system _dlnaurl.
Can you review the changes in Pull Request 34 pertaining to these in system.class and ts.class, and maybe selectively revert them? (Or just revert the whole of PR34 to start with and see if the problem goes away.)
MymsMan said:
I have turned off chaserun processing for now and so far it has crashed again
Click to expand...
Did you mean "hasn't"?
 
Black Hole said:
That's as maybe, but why would it invoke mtdblockd? Or was that a red herring? If decrypt is blocked, why doesn't it fail gracefully?
Click to expand...
[mtdblockd] is a kernel dirver so presumably humaxtv accessing the flash memory. Perhaps lsof might provide some clues as to the open files.
 
prpr said:
Yes, well indirectly in system dlnaurl and system _dlnaurl.
Click to expand...

A few observations:
  1. system dlnaurl "$dir/helper.ts" is returning null even though the entries exist in the DLNA database
  2. Because of the not found system dlnahelper inserts another copy and then repeats system dlnaurl "$dir/helper.ts" which fails again!
  3. I had over a thousand helper.ts entries in my database before I did a DLNA reset!
  4. Potentially repeatedly adding entries to the database might be the cause of the mtdblockd high cpu and crash
  5. When adding the dlnahelper db entry no value is assigned to mimeType
  6. I couldn't see why a missing mime value would be affected by the changes in pull 34 but it is suspicious that the changes were dealing with mime type!
  7. I have had no crashes since turning off chaserun processing, BUT
  8. I had an overrunning recording last night,
  9. The system was in delinquent half-awake state (stuck not completing shutdown)
  10. This may be unrelated to the upgrade but I don;t like coincidences
  11. I have forced a reboot and will keep an eye out for overrunning recording and failed shutdowns
 
/df said:
Maybe this commit 'Make {system dlnaurl} handle any valid pathname for a file' is the problem? It could be necessary always to compare the [file normalize ...]ed filenames.
Click to expand...
Yes, that is the problem. The dlnahelper is deliberately using a link to the real ts file so that it doesn't conflict with the indexing of the real file by the humax so we must not use the normalized name.
I think it might work to create helper.ts as a hard link instead of symbolic link in system dlnahelper
Alternatively require the callers of system dlnaurl supply the normalized name when needed - are there many callers that don't
I could only find 3:
Code: 
webif/html/browse/play.jim:set dlna [system dlnaurl $url $urlbase]
webif/html/browse/index.jim:            [llength [system dlnaurl $file]]} {
webif/lib/ts.class:     return [system dlnaurl $file $urlbase]
 
Last edited:
This removal of 1 redundant line and old comments could also be added (from the thread on media list sorting):
Code: 
 diff --git a/webif/html/browse/crop/execute.jim b/webif/html/browse/crop/execute.jim
index bca7d78..d32cb30 100755
--- a/webif/html/browse/crop/execute.jim
+++ b/webif/html/browse/crop/execute.jim
@@ -70,10 +70,6 @@ set newname "$shname-[clock seconds]"
 puts "Renaming file group to $newname"
 puts "<span class=hidden id=fileparams file=\"$dir/$newname.ts\"></span>"
 ts renamegroup "$dir/$shname.ts" $newname
-exec /mod/bin/hmt "+setfilename=$newname" "$dir/$newname.hmt"
-# New nicesplice shrinks whilst cropping.
-# No longer required - nicesplice now sets this flag.
-#exec /mod/bin/hmt "+shrunk" "$dir/$newname.hmt"
 
Code: 
# find webif \( -name '*.jim' -o -name '*.class' \) -exec grep -Hn dlnaurl {} \;
webif/lib/ts.class:334: return [system dlnaurl $file $urlbase]
webif/lib/system.class:271:proc {system _dlnaurl} {file urlbase} {
webif/lib/system.class:307:proc {system dlnaurl} {file {urlbase "127.0.0.1"}} {
webif/lib/system.class:312:         catch {set ret [system _dlnaurl $file $urlbase]}]} {
webif/lib/system.class:338:     set ret [system dlnaurl "$dir/helper.ts" $urlbase]
webif/lib/system.class:348:                     set ret [system dlnaurl "$dir/helper.ts" $urlbase]
webif/html/browse/play.jim:18:set dlna [system dlnaurl $url $urlbase]
webif/html/browse/index.jim:219:                [llength [system dlnaurl $file]]} {
#
I think the best thing is to revert the commit e79e85af81 and instead make this change (that I was probably trying to finesse last year):
Code: 
diff --git a/webif/html/browse/play.jim b/webif/html/browse/play.jim
index 3eb8dc3..1f4b4a9 100755
--- a/webif/html/browse/play.jim
+++ b/webif/html/browse/play.jim
@@ -15,7 +15,7 @@ set vc [cgi_get vc ""]
 set url $file
 
 # Prefer to use DLNA server ... (necessary if encrypted)
-set dlna [system dlnaurl $url $urlbase]
+set dlna [system dlnaurl [file normalize $url] $urlbase]
 if {[llength $dlna]} { 
      set url [lindex $dlna 0]
 } elseif {[regexp {^(https?://(.+:.*@)?[[:alnum:].]+(:[[:digit:]]+)?)/} $urlbase x y]} {
 
/df said:
I think the best thing is to revert the commit e79e85af81 and instead make this change
Click to expand...
I'd come to the same conclusion.

This should all be up to date now on git, if someone would like to verify.
 
  • Like
Reactions: /df
Status
Not open for further replies.
Back
Top