• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Loss of playback point

X

xyz321

Well-Known Member
This is a problem I have seen for some time but it is difficult to pin down exactly when it first appeared. It can be intermittent in nature but it seems to be apparent in the following scenario.
  1. Make a recording which will result in the machine staying fully on when it completes (either an instant recording or a scheduled recording).
  2. When complete wait a few minutes then select from the recording list and start playing.
  3. Stop the playback before the end.
  4. Switch the machine into full standby mode.
  5. Startup the machine and try to resume the playback
  6. It will either start from the very begimning or from a few seconds in.
I suspect that it is a problem with recmon or its children since it doesn't seem to occur if the recmon process is killed off before the recording starts.

Has anyone else seen this problem?
 
It wont be Recmon itself - it is only detecting the closure of the media files by the humax but it could be something in the auto processing triggered by it.

I would suggest using the hmt utility from a telenet window to look at the resume point of the hmt file in the [Deleted Items]/webif-autdecrypt folder

Has the program been decrypted before you start watching?

My guess is that decrypt may take a copy of the hmt file at the start of processing and this copy does not reflect any changes made to the hmt subsequently.
 
Why - you think my post out of character? I was just saying that I think MymsMan is on the money.
 
Black Hole said:
Why - you think my post out of character? I was just saying that I think MymsMan is on the money.
Click to expand...
It did seem out of character IMHO. It didn't add anything to the discussion and did not seem like a regular BH post. Good to know that my suspicions were unfounded.
 
xyz321 said:
It turns out that the culprit is flatview. My guess is that it is holding a lock for too long or at an inappropriate time.
Click to expand...
Nicely narrowed down!
Flatview is set to trigger automatically as soon as a recording completes but I can't immediately see why it would do this. At least you have a way to reproduce it too so we stand a chance of working out what's happening.
 
I am surprised that Flatview is implicated since it creates links to the hmt and, AFAIK, doesn't update it.

xyz321 when viewing files are you selecting the Flatview entry or the one in the original location?

<speculation>
While flatview creates the links immediately on recording completion if the hmt is subsequently recreated (by renaming and copying) this can result in an inode mismatch which I think Flatview resolves by relinking to the version in the original recording - which could lose the resume point.
inode mismatches are detected during periodic auto processing
</speculation>
 
MymsMan said:
I am surprised that Flatview is implicated since it creates links to the hmt and, AFAIK, doesn't update it.

xyz321 when viewing files are you selecting the Flatview entry or the one in the original location?
Click to expand...
I am only acting on the one in the original location for these tests.

It has been a while since I last looked at flatview so I will wait until I have a good look at it before speculating further.
 
It seems to be a feature of humaxtv. The fault was still there when I disabled recmon but manually created a linked recoridng within the "My Video" tree without using flatview.

The best solution I have at the moment is to copy the hmt file and link the rest using something like:
Code: 
--- /mod/webif/plugin/flatview/auto.hook.old
+++ /mod/webif/plugin/flatview/auto.hook
@@ -270,9 +270,15 @@
                if {![file exists "$dir/$rec.$ext"]} continue

                if {![file exists "$::flatview::flatd/$rec.$ext"]} {
-                       file link -hard \
-                           "$::flatview::flatd/$rec.$ext" \
-                           "$dir/$rec.$ext"
+                       if {$ext eq "hmt"} {
+                               file copy \
+                                   "$dir/$rec.$ext" \
+                                   "$::flatview::flatd/$rec.$ext"
+                       } else {
+                               file link -hard \
+                                   "$::flatview::flatd/$rec.$ext" \
+                                   "$dir/$rec.$ext"
+                       }
                }
        }
        # Add a symlink to provide a hint as to where the original should be.
This does change the operation slightly in that there are now two independent playback resume points which may or may not be a good thing depending on your point of view.
 
xyz321 said:
It seems to be a feature of humaxtv. The fault was still there when I disabled recmon but manually created a linked recoridng within the "My Video" tree without using flatview.

The best solution I have at the moment is to copy the hmt file and link the rest using something like:
Code: 
--- /mod/webif/plugin/flatview/auto.hook.old
+++ /mod/webif/plugin/flatview/auto.hook
@@ -270,9 +270,15 @@
                if {![file exists "$dir/$rec.$ext"]} continue

                if {![file exists "$::flatview::flatd/$rec.$ext"]} {
-                       file link -hard \
-                           "$::flatview::flatd/$rec.$ext" \
-                           "$dir/$rec.$ext"
+                       if {$ext eq "hmt"} {
+                               file copy \
+                                   "$dir/$rec.$ext" \
+                                   "$::flatview::flatd/$rec.$ext"
+                       } else {
+                               file link -hard \
+                                   "$::flatview::flatd/$rec.$ext" \
+                                   "$dir/$rec.$ext"
+                       }
                }
        }
        # Add a symlink to provide a hint as to where the original should be.
This does change the operation slightly in that there are now two independent playback resume points which may or may not be a good thing depending on your point of view.
Click to expand...

Any process that updated the hmt after the flatview links were created would not be reflected in flatview.
e.g. Detectads bookmarks, sweeper or dedup title updates ...

I think this would create more problems than it solves unless you added code to keep the copies tightly in sync.
 
You must log in or register to reply here.
Back
Top