• 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.

Force DLNA Index, Auto Decrypt, Auto Shrink

ian_j said:
Is there any way that I can force the Humax to perform the above tasks?
Click to expand...

Use MediaTomb. You can do an immediate scan, or set the scan interval. Set it too short and you may find that the box starts thrashing, though.

If you want immediate access to your recordings from a PC, use FTP, eg, Filezilla. See the FTP package descriptions for username and password.
 
I don't understand how this helps. MediaTomb, FTP, etc require prior decryption, and WebIF decryption requires DLNA indexing...
 
Black Hole said:
I don't understand how this helps. MediaTomb, FTP, etc require prior decryption, and WebIF decryption requires DLNA indexing...
Click to expand...

Ah, I see. But you can force DLNA indexing with MediaTomb. Is the OP waiting for that, or decryption? I misunderstood.

I thought you could do an immediate DLNA scan with MediaTomb, and then follow with an immediate decryption, followed by another scan. That would not take two hours, would it?
 
You are missing something important. The DLNA indexing referred to is the native content sharing... which is the means to decrypt the content either "in place" (WebIF auto or manual) or by download. Mediatomb may well index the content, but all that it will do as a result is serve an encrypted or decrypted file according to its current state (only the native server, or handset OPT+ copy, or direct output to HDMI, have the ability to decrypt a file - not Mediatomb, FTP, or network file sharing).

The reason everything is on hold waiting for native indexing is because that is the necessary precursor for decryption, and if a recording gets moved after it has been indexed there is nothing to cause it to be re-indexed.
 
Ah! OK. Fair enough. I didn't know I had two DNLA indices. That seems inefficient to me, but what do I know? :p
 
I refuse to answer anyone who so negligently places an apostrophe where one has no place, and uses a where he should use an! :p
 
Some people vocalise the H - "haitch", in which case it would be a not an. However, like I said, blame the auto-correct.

How about getting back to the case in point: what do you find you need Mediatomb for?
 
Black Hole said:
Interesting. So your proposition is that it's not just the completed recording that gets indexed, but a sweep of the whole media folder is made?
Click to expand...
He's right. I don't have a way of triggering the re-scan manually though (yet).
 
Black Hole said:
what do you find you need Mediatomb for?
Click to expand...

I can choose what gets indexed by the media server. I can force a scan now or a periodic one. I also have Mediatomb on my Foxsat, so it made sense.

Anyway, things have moved on. Now that Cf/w 3.0 has ruined my box, I am backing up with the intention of doing an RMA, format disk, whatever it takes to get this box working again. And I don't presently have MediaTomb.
 
af123 said:
He's right. I don't have a way of triggering the re-scan manually though (yet).
Click to expand...

Have there been any further thoughts on how to trigger a rescan?

My goal is to be able to watch Countdown without ads with our afternoon cup of teas at 3:30.

Recently I had noticed that DetectAds was not processing the recording until after the start of recording of The Chase at 5:00, I thought that the problem was because the box was going to sleep between 3:00 and 5:00 so I scheduled a weekday reminder for that period but it actually made the problem worse because the DlNA index didn't kick in until the end of The Chase.

I have solved the problem by splitting the reminder into two periods 2:59-3:12 to allow the recording to finish and for Flatten to move the recording and then another reminder from 3:15 to 5:00 to cause a restart and trigger the DLNA scan, decryption and Detectads processing.
This works but is cumbersome to set up and could fail if we happen to be watching TV at the time the reboot is scheduled and it would be a lot better if Flatten and Sweeper could initiate a DLNA rescan when they do something that invalidates the Index.

Looking at the logs I see that files are still locked and cant be Flattened at 15:00 but are Flattened at 15:10, then following the reboot Decrypt processes the file from 15:20 to 15:22:32 then DetectAds processed the recording from 15:30 to 15:39 so the recording is available for use at 15:40

It can be seen that quite a lot of the elapsed time is actually spent waiting for the next 10 minute cycle for the next phase of processing. While some delays are inevitable since it not possible to predict how long it will take to process a file it seems it might be possible to reduce some of the delays by rescheduling the scans slightly.

Most TV shows are scheduled to end either on the hour or half hour so although they some times finish (AR) a few seconds early they are unlikely to be indexed for decryption by the routine :00 or :30 scan but there would be a better chance if the routine scans were on the odd minute :05, :15. :25. :35. :45, :55.
Is there any ability to modify the scheduling of the Auto scans? Leaving the DetectAds scans on the even minutes would then reduce the delay between completion of decryption and ad detection.
*EDIT* I have now edited Chrontab to move the Auto scan by a few minutes and will see next week whether it makes the expected improvement
 
Last edited:
Flatten is causing your delay. It baulks the DLNA indexer by moving the recording, DLNA indexing is a prerequisite for decryption, and decryption is a prerequisite for ad detection.

(Sorry if I've read your post wrong - it's early, I'm about to hit the road, and I just skimmed it.)
 
Black Hole said:
Flatten is causing your delay. It baulks the DLNA indexer by moving the recording, DLNA indexing is a prerequisite for decryption, and decryption is a prerequisite for ad detection.

(Sorry if I've read your post wrong - it's early, I'm about to hit the road, and I just skimmed it.)
Click to expand...
I understand that Flatten is causing the delay, hence my explanation of my attempts to reduce the delay by introducing a reboot to trigger an DLNA rescan and my asking whether there was any progress towards finding a better way of triggering the rescan.

Obviously you can say stop using Flatten and the problems will go away but I like what Flatten does and dont want to give it up. I have a, probably irrational, dislike of having to navigate in and out of series folders to find the single episode of the program that I am going to watch and then delete - I much prefer to have a simple list of programs to be watched at the top level of My Videos.
I could try to use a Sweeper rule to move the files after they have been decrypted and detectads has been run but there is no flag or other indicator to indicate when the process has completed so I would have to rely on Age which could be unreliable. If I was able to automate the process to run NiceSplice to crop out the ads then I could use the Shrunk flag but it isn't currently possible to run a process after Detectads
 
I've noticed something that could enable decryption to run on a recording that hasn't been DLNA indexed yet. Obviously this would involve programming the following method into the CFW decrypt software, so the rest of this post is aimed mostly at the developers:


Telnet onto your humax and create the following zero length files:

Code: 
cd "/media/My Video"
for f in ts hmt nts; do
  touch webif_dlna_helper.$f
done

Then use your favourite method of forcing a DLNA rescan. The above files will become indexed (but they don't show up in the humax on-screen menu, which is good). I used the following jim tkl script to obtain the URL since the web interface doesn't like the empty files:

Code: 
#!/mod/bin/jimsh
source /mod/webif/lib/setup
require ts.class

set tsfile "/media/My Video/webif_dlna_helper.ts"
set ts [ts fetch $tsfile]
# lassign [$ts dlnaloc "127.0.0.1"] url
lassign [$ts dlnaloc] url
puts "URL: $url"

Now for the neat part. You can replace the "webif_dlna_helper.*" files with symbolic links, pointing to a file that has just been moved (and is therefore un-indexed):

Code: 
cd "/media/My Video"
for f in ts hmt nts; do
  rm -f webif_dlna_helper.$f
  ln -s <the file that you're interested in, minus extension>.$f \
          webif_dlna_helper.$f
done

...and you can now download/ decrypt the file that you just linked to by using the URL of the "webif_dlna_helper.ts". Obviously you'd have to leave the "webif_dlna_helper.*" files on the system at all times so that they remain indexed. If someone wanted to develop this into the decrypt software, then it would probably require a lock to prevent 2 decrypt sessions using the links at the same time.
 
Blindingly obvious when you think about it (with hindsight), but nobody thought of it till now.
The decrypt automatic process is single instance/serialised anyway.
 
Very interesting. I have used a symbolic link to access the streamer file, but also did not think of this.
 
You must log in or register to reply here.
Back
Top