-
The forum software that supports hummy.tv has been upgraded to XenForo 2.3!
Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.
New feature request: bookmarks into the cut recording
- Thread starter mihaid
- Start date
Saving the new bookmarks can fail (more often than not in my several tests) when run automatically after cropping as part of the "Perform crop" function because the newly cropped file is "in use". Unless you watch carefully you might not notice the failure until you play the cropped show, because the error message is shown in a slide-down display that quickly disappears.
Is the settop program opening it for DLNA indexing, thumbnail generation or such? If so, we need a more sophisticated approach than the current one which is just clicking the hidden "Save new bookmarks" button programmatically after the cropping has finished. As a minimal solution, the bookmark save should be verified either through a success return from the API used or just by checking for bookmarks in the cropped show, and otherwise the "Save new bookmarks" button should be unhidden so that the user can retry.
Is the settop program opening it for DLNA indexing, thumbnail generation or such? If so, we need a more sophisticated approach than the current one which is just clicking the hidden "Save new bookmarks" button programmatically after the cropping has finished. As a minimal solution, the bookmark save should be verified either through a success return from the API used or just by checking for bookmarks in the cropped show, and otherwise the "Save new bookmarks" button should be unhidden so that the user can retry.
Black Hole
May contain traces of nut
I have never noticed this happen. The majority of the crop operations I perform happen to be on a HD-FOX, and I review the post-crop to check whether it needs adjusting.
That is not to discourage adding safety interlocks, but it raises a question whether there is something unusual about your setup.
Last edited:
What turns out to be unusual is that the machine is a(n) HD-FOX with my build of minidlna running, and that is what is accessing (presumably indexing) the newly cropped .ts file.
Although it's easy enough to copy the new bookmark list and re-apply it (if you catch the problem), I'll propose a patch to catch an unsuccessful attempt to add the new bookmarks.
I didn't see the same problem with the HDR-FOX, but IIRC it has been determined that its DLNA index is not continuously updated.
Although it's easy enough to copy the new bookmark list and re-apply it (if you catch the problem), I'll propose a patch to catch an unsuccessful attempt to add the new bookmarks.
I didn't see the same problem with the HDR-FOX, but IIRC it has been determined that its DLNA index is not continuously updated.
Black Hole
May contain traces of nut
MymsMan
Ad detector
I've seen spurious in-use problems with detectads but haven't tracked down the cause, dlna is a likely problem
I'm experimenting with a retry loop if I detect files in use but the problem is that there are still timing windows - something could open a file an instant after checking the inuse status
I'm experimenting with a retry loop if I detect files in use but the problem is that there are still timing windows - something could open a file an instant after checking the inuse status
Black Hole
May contain traces of nut
Do the Humax processes not respect an in-use status themselves? If so, it will always be a problem. If not, the usual method for obtaining control of a file in a multi-process system is:
Attempt to open the file. If successful, you have ownership and other processes are locked out. If unsuccessful, something else has ownership - try again later.
Looking at the status first, before opening, invites a problem of timing windows.
Oatcake
Member
I have an observation about disappearing bookmarks (ones that are set by the custom software). This particular issue isn't caused by file locking. Sorry if this is already known.
If you are watching programme A, and then decide to change its bookmarks via the custom software, then pressing "STOP" before changing the bookmarks is not sufficient. You have to press "STOP" and THEN start playing a different recording before you can reliably change the bookmarks for programme A.
The disappearing problem is easy to reproduce:-
- Start watching a recording on the TV.
- Press stop.
- Change the bookmarks of that programme via webif (or via hmt command).
- ( Optional ) You can verify that the new bookmark setting was TEMPORARILY stored by using the WebIf (or the hmt command).
- Then press play on the TV (on the same recording). Now the bookmark changes will be GONE. They should be no longer be visible on either the SUI or the WebIf (this is what happens for me anyway).
Oatcake
Member
A FULL DLNA sweep is triggered when:-
- The Humax has just finished recording a programme
- The user has just deleted a recording via the SUI
- Turn content sharing off and on in the settings
- Turn the Humax off and on
- ...there may be other events, but I doubt it
MymsMan
Ad detector
How are you timing the sweep? What indicates that a sweep is running?
MymsMan
Ad detector
I hadn't known about this but can confirm it happens,
How we can detect and solve this will be an interesting problem, hopefully it is fairly rare but I wonder if it also affects viewing a recording shortly after it has completed recording
Oatcake
Member
I timed the sweep by:-
- Create a recording that isn't indexed (one easy way to do this is by renaming a recording via the WebIf file browser)
- Trigger the sweep
- In the WebIf file browser repeatedly hit the "refresh" (browser button) while viewing the un-indexed file. The little green "indexed" icon will appear at some point. Sometimes this happens quite quickly, but I have noticed delays of over a minute. I've never had it take longer than 2 minutes.
- And yes, I'm probably a bit OCD (or impatient) for noticing this!
Nothing that I know of. You only know that the sweep has happened by watching an un-indexed recording until it becomes indexed.
EDIT: It seemed logical to me that the Humax might perform such a sweep after a recording is made or deleted.
BTW: I use the undelete package. On the occasion when I need to trigger a sweep then I have a small music video recording that I delete via the SUI, and then afterwards move it back out of [deleted] using the WebIf.
Last edited:
Oatcake
Member
One suggestion is to have a new log file "bookmarks_history.log" or similar. It could contain a single line for each recording that has been bookmarked by the WebIf/ ad detection etc. The format for the file could be single lines like this:-
hmt +setbookmarks=XXX file.hmt
...then the user can then copy and paste the appropriate line in the rare event that this happens.
To make it more accessible then a new Webif page could be created to do this - with a dropdown list of recordings. But this sounds like a lot of work.
Black Hole
May contain traces of nut
Not exactly - only during turn-off (not as a result of turning on).
Oatcake
Member
OK - so in other words if the box crashes then a DLNA scan does not take place when the Humax is turned back on? I have not investigated this scenario.
EDIT - but it does not affect the accuracy of my original statement. Turning the Humax off and on DOES produce a DLNA sweep at some point!
Last edited:
Black Hole
May contain traces of nut
This.
The test is
[system inuse $file] which looks for $file (the file.ts passed from Browse Files) being open. There's no check on the .hmt. I guess the intention is mainly to avoid clashing with the settop program's use of recordings, where bookmarks can only be set if the recording's .ts is open. As post #10 implies that bookmarks set while a recording is playing will be overwritten, this is a Good Thing.
