• 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

Drutt said:
Does it allow you to record 3 channels on the HDR? :cool:
Click to expand...
It should do as we can already do that by watching the third programme if it's on the same mux as one of the recordings and then doing rewind/record when one of the recordings has finished. This makes the process easier though : )
 
mihaid said:
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.
Click to expand...
This is expected - when you switch channels it starts overwriting the previous buffer, so how much you get depends on how long you were on the other channel.
mihaid said:
I noticed that there are new edit folders []
Can I delete the *edit folder ?
Click to expand...
Yup - obviously make sure you've not left any recordings in there before you do ;)
 
so say your buffer is 10min. you switch for 15sec. you realise and switch back, wait 15sec. record previous buffer. you should end up with the original buffer less the first 15 seconds which were overwritten. and this is because the buffer gets written / overwritten from beginning?
 
No, it will have just have (almost) 2 minutes of the 2nd channel, linked with the .hmt from the current (ie first) channel.

This won't actually play, as the program/channel ids in the hmt won't match those in the stream. This is why you have to wait at least as long back on the first channel, so the unwanted bit gets overwritten, and the bit you wanted becomes the second "section" in the buffer.

At some point I plan to change the behavior from "capture second section" to "capture second section with ids that match the current hmt", then at least you wouldn't have to wait, and won't be possible to end up with non-playing recordings with mismatched ids.

For those who are interested and like mucking about on the command line, the new option in nicesplice is "-tsr <num>" where num is the section of the tsr to grab. It finds "sections" by looking for differences in the frame timestamps that are over a threshold.
eg to get the current buffer you use something like

nicesplice -in /media/drive1/.tsr/0 -out outfile -tsr 0

Its up to the caller to make sure that the ids in 0.hmt matches the section being captured. The magic folders script backs up 0.hmt every few seconds and uses that backup if 0.hmt doesn't exist (as is the case when playing a recording).
 
Im trying to join two files, it appears everything looks fine and a right length file appears in the done folder but when played the first file plays fine but the second half I get no picture or sound and the message "The channel is scrambled or not available". Both files played fine before joining
 
nofuse said:
Im trying to join two files, it appears everything looks fine and a right length file appears in the done folder but when played the first file plays fine but the second half I get no picture or sound and the message "The channel is scrambled or not available". Both files played fine before joining
Click to expand...

Are the recordings from the same channel? Unless Drutt has fixed it, you can't join files from different channels. To support that would require fixing up the packet IDs for the video and audio streams in the second half to match the first.
 
No, I'm afraid I did make a start on that, but never got it working. Should only be a rare problem, as recordings you want to join are nearly always from the same source, but I might look at it again though if there is demand though...
 
Black Hole said:
Perhaps the first file was decrypted but the second file was not?
Click to expand...

Now you say that....Firstly I tried to join two files then as they were on different channels I thought that may have been the problem so I tried two on the same channel and the same thing happened, but I've just remembered the second half was decrypted.

I'll try again tomorrow.
 
May I first say thanks for this add-on, which I have found invaluable and use on a daily basis.
However, I have noticed that on most occasions when I crop an HD recording, on subsequent viewing the time elapsed is not properly updated ie the time as shown on the playbar and front display can be some minutes behind the actual position in the programme. Sometimes it will catch up of its own accord, other times it will last until the end. To clarify, these behaviours are on a per recording not per viewing basis and are seem to have started when the shrink functionality was added; they are not seen when the shrink function itself is used. This is only a problem when you want to search in the programme or stop it part way through and so have not said anything before now but would like to get it resolved if possible. I have to say I'm surprised that no-one else has mentioned it; maybe it's just my system?
 
Black Hole said:
Are you shrinking before splicing?
Click to expand...

No. I mostly use the crop function to "top and tail" recordings I want to keep, ie remove the minute or so after the end of the actual programme to save disc space. This is when the problem occurs, If I manually stop recording at the end of the programme and then simply shrink it I don't see the problem. I don't recall ever having shrunk then cropped.
 
I'll have a play and see if I can replicate it, but any more clues appreciated (eg is it only if you remove stuff from the start, is it definitely only HD recordings, does the problem occur if the recording is shrunk beforehand?)
 
Hi, hopefully I have come to the right place to ask my first question...basically I just wanted to get a little bit more info on Nicesplice (1.4 & 1.2) as I appear to have experienced a problem with it.

I'm on a HDR-Fox-T2 box with the latest firmware and installed packages.

Previously I have recorded programs and if I felt they might be viewed again I would copy them to an external hard-disk and convert them to MP4 (so available on my portable device as well)

I had used the Nicesplice features and cropped some of the files to be transfered over the past few months (usually on-box). However, I had recently decided to remove the adverts from the recordings to be transfered in dull moments on TV or when listening to the radio. All seemed to work fine. Multiple in/out points (normally about 10 or 12 in total per recording so well under the 32) were set and the "done" output then transferred externally to be converted.

To my surprise when I viewed one of these multi-cropped recordings I found that although the crop segment had been removed it had been filled with a image still (basically the initial frame of the crop held for some 4 or 5 minutes). Whilst the recording length had only reduced by about a couple of minutes rather than the 25+ expected.

When the "done" located recording is viewed via the HDR the crops are removed (run time is reduced proportionally i.e. typically 25 minutes less), but when viewed externally the crops are padded back in.

I initially thought it was version problems etc so updated all packages etc and retried. However, the same problem.

The idea is to cut 20 or 30 minutes of dead recording for external storage to reduce space/conversion time, but it is being padded out. So no reduction/time saving at all. What is the situation here? Why would the apparently removed crop become padded.

I tried on-box editing and via Webif to see if that made a difference. No it did not. However I did screen grab the Webif outputs showing the edit points and file/time saving stats etc. But as I say the edits become padded when transferred externally. Why does this happen? Are you/anyone aware of this padding aspect? Is there a solution?

Regards
 
The bookmarks that are added to a recording are used by the Custom firmware for a few different things, initially they were only used as 'cut' points for On The Box edits, however more recently a single bookmark has also been used to point to an image that will be used to replace the standard Thumbnail picture displayed on your TV next to the description in the 'Media' section. It looks like the two bookmark processes are interacting with each other
 
Gromit said:
Previously I have recorded programs and if I felt they might be viewed again I would copy them to an external hard-disk and convert them to MP4 (so available on my portable device as well)
Click to expand...
Would you mind sending me a PM with what program you use and any settings for transcoding to mp4. Do you keep the 5.1 surround?
 
You must log in or register to reply here.
Back
Top