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

[nicesplice]+[nicesplice-magic-folders] On box video editing

Hmm. Not sure what is going on there - would you be able to stick the recording (unencrypted) on 4shared or dropbox, and I can debug what is doing wrong?
 
Black Hole said:
It's 2GB - how long would that take me to upload? I'll send it on a DVD if you like!
Click to expand...

Duno - how fast is your internet? ;) There is a little more debug output in the new executable so there may be some more clues if you wouldn't mind trying that. From there I could send you an executable with even more targeted debug output... Is this a problem you've only seen with one specific recording?
 
Several people have reported that clips of only a couple of minutes don't work, although I have successfully taken clips of about a minute out of a half hour recording. Hypothesis: it's more dependent on the proportion of the recording you want to extract than the absolute length.

PM me your address and a DVD with the data on it will wing your way - I'm sure that will be more efficient than try this, try that. The bookmarks are set, and if you don't get the same results that will be indicative also. Further, when you have a solution it will be useful to try it on the same data here.

Meanwhile I'll give this new executable a try and post back.
 
Drutt said:
Hopefully done a fixed version - would you (or anyone else with recordings that failed to edit to test on) be able to give it a spin for me before I roll it into a package update?
I've uploaded a new nicesplice executable here
Drop that over the old one in /mod/bin (and probably need to do a "chmod 755 /mod/bin/nicesplice" to make it executable again).

Steve
Click to expand...

Would anyone been able to give this a try, especially those with recordings that have failed? Its been working ok for me but I've not done that much editing, so would appreciate a little more testing before releasing it... Or shall I just release it - what's the worst that could happen... ;)
 
Black Hole said:
Oops - sorry this got forced down my stack and I've not looked at it. Bit short of playtime at the mo...
Click to expand...
I know the feeling...

Jack616, are you able to take look, as you reported having a lot of the "oversize chunk" errors? Thanks!
 
Just uploaded nicesplice 1.2
Main highlights are:
- Frame size buffer overflow errors should be a thing of the past.
- Edited recordings have useless epg data packets removed (shrinking recording size by 5 to 20%).
- Progress bar on command line.
- Fix for bookmark on frame 0 bug.
- Allows recordings with truncated.ts files (quite common) to be appended to.

Any problems shout here. Be sure to keep you original files until you're sure the edited recording is ok. There have been a lot of under the hood changes since the last version, and not as much testing as I'd like ;)
 
Thanks for the update. A few problems with my bookmark at frame zero recording. It is much better in that it doesn't fall over immediately any more but the cropped recording starts from several minutes in.

The redundant EIT data has not been stripped from the file.
 
nicesplice 1.3 just uploaded - been sitting on this one too long!
Fixes xyz321's problem above, which turned out to be a general problem with recordings that were retrospectively recorded, ie included a portion of the timeslip buffer (only possible on HDR).
 
nicesplice 1.4 and nicesplice-magic-folders 1.2 have just been uploaded.

I've added some experimental support for turning the timeshift record buffer into a usable recording.

The easiest way to use it at the moment is via magic folders:
Go to [edit]/[tsr] and remove the "?" from "GrabCurrentTimeShift?"
After a little while (depending on timeshift size), the current timeshift should appear as a new recording in the [edit]/[tsr] folder.

"GrabPreviousTimeShift?" works in a similar way, but attempts to grab what is left of the previous time shift (useful for when you accidentally change channels, and the time shift you wanted is lost). The caveat at the moment is you have to first switch back to the channel you wanted, and wait for at least as long as you were switched to the unwanted channel.

Its only tested on the HD at the moment, where it is most useful as there is no "rewind and record from here" facility.
I'm interested to hear how/if it works on the HDR.

Also changed the naming of "special" folders from the "*" prefix to "[]" notation to match other packages, so just delete the "*edit" once you've cleared out any recording you have in there.
 
Drutt said:
"GrabPreviousTimeShift?" works in a similar way, but attempts to grab what is left of the previous time shift (useful for when you accidentally change channels, and the time shift you wanted is lost). The caveat at the moment is you have to first switch back to the channel you wanted, and wait for at least as long as you were switched to the unwanted channel.

.
Click to expand...
So see if I understand.
I am currently watching a buffer say 30 min behind live. I accidentally change channel or my machine starts recording 2 channels. (Would it actually work in the second case? Presumably when I get the message to change channel I could record the current buffer)
After 10 seconds I realise I messed up the buffer, what do I do now?
 
mihaid said:
So see if I understand.
I am currently watching a buffer say 30 min behind live. I accidentally change channel or my machine starts recording 2 channels. (Would it actually work in the second case? Presumably when I get the message to change channel I could record the current buffer)
Click to expand...
Correct.
You would also use "GrabCurrentTimeShift" if you accidentally started playing an existing recording, causing the buffer to reset (it does on the HD at least).

mihaid said:
After 10 seconds I realise I messed up the buffer, what do I do now?
Click to expand...
Switch back to the channel you were first on (basically to ensure .hmt is from the correct channel), wait at least 10 seconds (kind of to ensure the unwanted buffer is now overwritten), then activate "GrabPreviousTimeShift?". I have a few ideas to simplify this in the future, but thought I'd get it out there first.
 
Has anyone had a chance to test tsr grabbing on an hdr yet? Did it work as expected? Any feedback appreciated...
 
That would imply that I occasionally watch live TV!
Will have a play when I've finished watching some recordings.
 
Drutt said:
Has anyone had a chance to test tsr grabbing on an hdr yet? Did it work as expected? Any feedback appreciated...
Click to expand...
I've tried it also. they both work. On the previous tsr I noticed that there seems to be a missing period at the beginning of the buffer, a few seconds? I couldn't vouch for the current tsr.

I noticed that there are new edit folders []
Can I delete the *edit folder ?
 
Worth pointing out as I didn't mention it explicitly above: One of the most useful features it gives to the HD is a limited ability to record 2 channels at once (as long as they are on the same mux), as you can record one, watch another, then grab the tsr. Its good that the 4 main HD channels are on the same mux :)

Does it allow you to record 3 channels on the HDR? :cool:
 
You must log in or register to reply here.
Back
Top