Switch Content Share on and off automatically (By schedule? On boot?)

TonyC

Member
As usual, apologies if this has been discussed before; a search didn't show anything.

I've a Fox T2 running CF. About half the things it records get FTPed off, edited and put onto my NAS (running Twonky v7) for convenience and to save disk space. To do this, I have to have Content Share on, in order to do auto-decrypt.

Unfortunately when Content Share is on, it somehow disrupts the link between the NAS and my TV, so DLNA streaming gets interrupted every few minutes. Possibly this happens whenever the Fox starts decrypting a new file, possibly it's just at random. Either way it's annoying. The work-around is to turn Content Share on at night, before I go to bed, and back off in the morning, so it can do the decrypting while I'm asleep.

Could it be possible to do this switching automatically, by schedule? A partial solution would be to switch it off when the 'Fox does its daily reboot at 5 am - maybe an IR command could do this, because the menu is in a "known" state after boot? At least that way the NAS -> TV link is reliable.

I have DLNA-protect running; I presume without it, and with Twonky v7, I would have a lot more problems...

I can't see any options on either the TV or the NAS that would help with this.

Thanks in advance!
 
I have DLNA-protect running; I presume without it, and with Twonky v7, I would have a lot more problems...
DLNA-protect is just a firewall rule so it should be possible to write a firewall rule to block whatever the Humax DLNA server is doing to interfere with the NAS - TV streaming. A CRON job could then insert and remove the rule at specific times.
 
Ah, I hadn't thought of that. I don't actually want to Share Content, I just want auto-decrypt to work. So a permanent firewall rule that made the 'Fox entirely invisible to both the TV and the NAS, in either direction, would be fine. Is some kind person able to advise the necessary mystic incantation?
 
So a permanent firewall rule that made the 'Fox entirely invisible to both the TV and the NAS, in either direction, would be fine. Is some kind person able to advise the necessary mystic incantation?
I dabble with iptables but I am no expert. The notes to the DLNA-Filter package say "DLNA-Filter will block access to the Humax DLNA server if the Settings for DLNA-Filter package is left blank" so try installing DLNA-Filter and leaving settings blank.
 
...so try installing DLNA-Filter and leaving settings blank.
That's exactly what I have done. And it clearly is basically working, because the 'Fox doesn't appear on the TV's list of possible DLNA servers. And yet it is absolutely consistent that turning Content Share on disrupts NAS -> TV streaming.
 
Have you checked the auto.log log file to see if something is going on there? There could be something in the background processing causing this. Are all of your packages up-to-date?
 
I'm not quite sure what I'm looking for in auto.log, but nothing stands out as an error-type message.
I can see a lot of lines like "Flatten failed to remove directory", I presume because I have dozens of folders all marked as "noflatten"
There are some other sets of lines like "SHRINK: /media/My Video/Breaking Bad/Breaking Bad_20150707_2258"..." Done... 1.04 GiB in 106.883 seconds - 10.01 MiB/s"
And when Content Share is on I see groups of lines like this (apologies that order is, of course, reversed):
4569 07/07/2015 21:06:37 - Done... 781.43 MiB in 73.018 seconds - 10.7 MiB/s
4568 07/07/2015 21:06:37 - Removing/binning old copy.
4567 07/07/2015 21:05:24 - DLNA: http://127.0.0.1:9000/web/media/8712.TS
4566 07/07/2015 21:05:24 - DECRYPT: /media/My Video/To MPEG/Doctor Who_ Genesis Of The Daleks_20150706_1035


My packages are fairly up to date, but I'll update them again in case it makes a difference.
 
The "Flatten failed to remove directory" are produced when a recording is in progress and so the directory (which isn't named in the message) can't be flattened yet.
Really they and the associated blocking file message should only be produced when a higher trace level is turned on since they don't represent an error and are not useful.

The Decrypt set of messages are normal - decryption can only take place when content share is turned on
 
The "Flatten failed to remove directory" are produced when a recording is in progress and so the directory (which isn't named in the message) can't be flattened yet.
I just love messages like this.
Presumably it can be fixed fairly trivially:
Code:
humax /mnt/hd2/mod/webif/plugin/flatten # diff -u auto.hook~ auto.hook
--- auto.hook~
+++ auto.hook
@@ -37,7 +37,7 @@
  }
  }
  if {![system rmdir_if_empty $dir]} {
-  log "Flatten failed to remove directory" 0
+  log "Flatten failed to remove directory '$dir'" 0
  foreach l [system rmdir_if_empty $dir 1] {
  log "Blocking file: $l" 0
 
I would make a further minor change to the logging level for the messages
Code:
if {![system rmdir_if_empty $dir]} {
-  log "Flatten failed to remove directory" 0
+  log "Flatten failed to remove directory '$dir'" 1
  foreach l [system rmdir_if_empty $dir 1] {
-  log "Blocking file: $l" 0
+  log "Blocking file: $l" 1
 
Just to update this old thread, in case anybody else has the same issue: I recently got a new TV, and the original problem (that the NAS -> TV DLNA streaming was unreliable with Content Share on) has gone away.
 
Back
Top