Crop Failed

Black Hole

May contain traces of nut
I renamed a recording via a remote Humax SUI (network share) and set bookmarks approximately 4 minutes apart in a 36-minute recording to extract a small part. Then in the WebIF I tried to run Crop.
Code:
Processing Alex with Anton_20131022_1829
Moving recording to /media/My Video/[Unclassified]/_original
Runtime Error: execute.jim:43: Can't open /media/My Video/[Unclassified]/_original/Alex with Anton_20131022_1829.hmt
at file "execute.jim", line 43

Any clues? Crop doesn't need DLNA indexing does it? I imagine the option would have been unavailable if so. Of course I tried it again and got the same again. The file plays no problem.

As a long shot, I renamed the file again to remove the spaces, but got the same result.

By Telnet I can't see anything odd about the files listed by ls, and subdirectory _original is empty.
 
I feel I may be teaching my grandmother ...
but, at one point I got some oddities when I renamed a file(set) and didn't see what I expected when looking at the files for processing them ( joining them, I think). I traced it to the fact that I'd renamed the files,but hadn't changed the identities to match. Your obvious next question would be - what are these identities, to which I have to reply that I cannot for the life of me remember. I seem to remember that it showed up in the WebIF somehow.
Sorry about the vagueness, but I hope there is something there for you.
 
Many thanks for your input, but I am not sure what would have upset the process to make a working copy of the original file. There may be something in that I was manipulating things remotely.

I'm waiting for some guru insight into what might have gone wrong with execute.jim to result in no file found at line 43.
 
Any clues? Crop doesn't need DLNA indexing does it? I imagine the option would have been unavailable if so. Of course I tried it again and got the same again. The file plays no problem.

Nothing comes to mine, sorry. No, DLNA indexing isn't required.
 
I renamed a recording via a remote Humax SUI (network share) and set bookmarks approximately 4 minutes apart in a 36-minute recording to extract a small part. Then in the WebIF I tried to run Crop.
Code:
Processing Alex with Anton_20131022_1829
Moving recording to /media/My Video/[Unclassified]/_original
Runtime Error: execute.jim:43: Can't open /media/My Video/[Unclassified]/_original/Alex with Anton_20131022_1829.hmt
at file "execute.jim", line 43
Ah, looking at the code, it is trying to run nicesplice at that line. I don't know what the problem is with this infernal utility (the author seems to be AWOL) and its grossly excessive use of memory.

Nicesplice is beginning to look a bit yellow and acidic.
 
Prpr's swapper package (on the link above) seems to have cured a few issues I had with general performance in webif if I was recording and copying at the same time.

Could this package be moved to the general package server?
 
I will assume guru status if this solves your problem :)
Personally I'll elevate you to BYT status if you can come up with a graphical builder for the sweeper config file.

I will try out the virtual memory mod when I get the chance.
 
I've spent the last few evenings working on a caching system for nicesplice to reduce its memory footprint, and turn it back into a sweeter fruit.

For anyone interested in the technical details, the issue is that it loads the entire nts (the videos time/position index) into memory so it can easily random access into it as it goes about its business. It also creates the entire new nts in memory before saving it out (though I did optimise it in the last release to create this over finished with portions of the input nts). To allow for the largest supported video (about 8 hours worth) I allocate up front for this worst case amount, and this has always left plenty of headroom clear on my system, but others are obviously running into problems. It now caches smaller sections of the nts in memory and writes out the new nts in chunks as it goes, storing a few key times etc internally.

Its mostly working now, just ironing out a few bugs, and testing with the various flavors of recordings that are possible (timeshifed ones being the nastiest). As well as reducing memory usage it should allow longer lengths of videos to be edited. Should be ready in a day or two...
 
Does it do this memory allocation even though you don't give it any command line parameters? It seems so, as that's how it crashed for me.
It is all moot anyway now since running with swap file. There are no downsides to this that I have found. Indeed, the box used to crash after about 2 weeks (I suspect due to memory issues) and mine's been running 19 days now and is still OK (and with a little bit of swap used).
 
I've noticed that if you crop out advert breaks, the resulting file plays fine on the Hummy (there are a few seconds of sound dropout after the cropped sections) but Android video players like MX and BS think the files are longer than they are and get a bit confused at the points where sections have been cropped. Is this due to this sidecar files? Sorry if a bit off topic, but I thought I'd mention it as you are working on updating the package.
 
You could always junk the sidecar files and use the oh-so-advanced AV2HDR-T2 to re-generate them.
Oh yeah, I forgot, said piece of crapware can't even process files recorded on the Humax itself without crashing.
Arf, arf.
 
You could always junk the sidecar files and use the oh-so-advanced AV2HDR-T2 to re-generate them.
Oh yeah, I forgot, said piece of crapware can't even process files recorded on the Humax itself without crashing.
Arf, arf.
I don't know if it is the sidecar files that are causing the problem. I have not tried the AV2HDR-T2 software. I am grateful that many people have done a lot of work that has improved the function of the HD and HDR-Foxes, and shared it with other users for free. Thanks for the Swapper package; my HDRs are running much more sweetly after installing it.
 
Does it do this memory allocation even though you don't give it any command line parameters? It seems so, as that's how it crashed for me.

Yup - it was just lazy static array. No longer though.

It is all moot anyway now since running with swap file. There are no downsides to this that I have found. Indeed, the box used to crash after about 2 weeks (I suspect due to memory issues) and mine's been running 19 days now and is still OK (and with a little bit of swap used).


Still better to fix the cause rather than the symptom. Its something I've been meaning look at for ages, as the maximum video size / length limitaions have also caused a few problems over the summer (reading festival, Wimbledon etc) Unfortunately paid work has kept me away from it until now...
 
a couple of "-"s in the wrong places? Just fixed, and added -tsr (used to process the 0.nts when grabbing the time shift buffer)
 
Back
Top