Thanks Black Hole, that is good to know. I have already done the factory reset option. I am more thinking that it could be interference from things like channel renumbering etc which going back to standard and doing a factory reset would illuminate. I just need to find a time when I am free for a few hours and it isn't meant to be recording anything to try a few of these options.
-
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.
No AR markers are being received
- Thread starter rowanmoor
- Start date
I think I have solved it now. Following MontysEvilTwin's suggestion I turned off the default padding last night. I have set most of my scheduled recordings to have padding in Web-If for now. I set a couple of test AR recordings for this morning and they both started and judging by the file sizes both stopped at the correct time. I am at work so can only go by what Web-If shows me for now so I can't view them to be sure. A 3rd test on Ch5 has started recording but is not yet due to finish. That is a 100% success rate so far compared to a near 100% failure rate before changing the default.
I will set a few more tests for this afternoon and see.
That would suggest that AR recordings are not reliable if you have padding as the default.
I have also seen from the logs that arbookmarks specifically skips any AR recordings and doesn't even try which seems sensible.
I will set a few more tests for this afternoon and see.
That would suggest that AR recordings are not reliable if you have padding as the default.
I have also seen from the logs that arbookmarks specifically skips any AR recordings and doesn't even try which seems sensible.
DelftBlue
Member
On my HDR, if both recursive auto-decrypt and auto-shrink are set, I found that 9 times out of 10, auto-shrink works first, and then auto-decrypt catches up later - which means that ARBookmarks reports "Recording has been shrunk, cannot process" in auto.log.
As I find ARBookmarks really useful, I've disabled auto-shrink in order to allow auto-decrypt to get to the files first and then create the useful beginning and end bookmarks. Auto-shrink is then enabled intermittently to work on already decrypted files.
However, a 'set and forget' process would be easier, with both recursive auto-decrypt and auto-shrink concurrently enabled - is there any way to make auto-decrypt work first always? Or for auto-shrink to only process decrytped files? Or ARBookmarks run first before any other processing? Or something cleverer that is beyond my imagining ...
Webif version 1.0.12-1 fixes this. For any recordings which are scheduled for both decryption and shrinking, the shrinking will be deferred until decryption has occured. AR bookmarks hooks into post-decryption so that will also fire before shrink.
Code:
02/05/2014 12:07 - SHRINK: [/media/My Video/tbbt]
02/05/2014 12:07 - scanup: Found decryptr (/media/My Video)
02/05/2014 12:07 - /media/My Video/tbbt is also set for decryption.
02/05/2014 12:07 - /media/My Video/tbbt/New_ The Big Bang Theory_20140417_1959.ts - deferring shrink until decrypted.
02/05/2014 12:07 - scanup: Found decryptr (/media/My Video)
02/05/2014 12:07 - /media/My Video/tbbt is also set for decryption.
02/05/2014 12:07 - /media/My Video/tbbt/New_ The Big Bang Theory_20140501_2000.ts - deferring shrink until decrypted.The main problem seems to be that when the Humax is half-awake - for example recording something - it is not able to decrypt anything as the DLNA server is not running. It can however merrily shrink away and so it does, or at least did before this update.
DelftBlue
Member
Brilliant! Thank you.