Hello everyone

If I understand the code from Ralf right (I have not tried it) it makes you leave the MoviePlayer just like before, but the next time you enter the movie list, you will start at the position of the last movie watched.

Below I have included an alternative solution I have been using for the same problem. (The patch is slightly adapted to fit the 7/11 version, the same as Ralf compared to, I hope it still works...) When stopping the movie there is another menu alternative "Yes, returning to movie list" which puts you right back in the movie list on the right spot. No global variables and no confusing start position the next day when you want to start watching from scratch.

I have not done anything about the case when the movie reaches the end (yet). Is anyone hacking on this?

Ultimately, maybe there should be two more configuration questions:

What should happen when a movie ends?
Ask user / Return to movie list / Return to previous service / Pause

What should happen when a movie is stopped?
Ask user / Return to movie list / Return to previous service

"Ask user" means to pop up the menu.

Of course, the "Return to" alternatives should only happen if the end of the movie is hit by normal playback, not when fast winding or jumping. (Winding can be easily checked but how to check if a jump caused it I currently don't know.)

Best Regards
Anders Holst

Hello,

For what it is worth, I am currently hacking on a fix for the small bug you mention. The fix is part of a larger issue: how to input text more conveniently from the remote control.

It seems from the current code that the developers thought something like this: "Overwrite mode is the best for editing text (or the easiest to implement?) so lets go for that. Then a new key press will always just overwrite the character in the current position. But what if we
want to add text to the end of the string, there is no character to overwrite there? Aha, lets always add a space to the end if the cursor gets there."

Now, if you insist on overwrite mode it would have been as natural to insert the new character at the end when and if the user presses any key at the end. As far as I can see in the code there is also no problem placing the cursor after the actual string.

What I am doing is to implement insert mode for editing instead of overwrite mode, and in the process I get rid of that silly hack with the space.

I intend to post my patches on the enigma2 development forum (at lists.elitedvb.net), but the patches tend to increase in size all the time since editing support is spread here and there through the code and I try to make my changes consistent throughout the whole code.

Best Regards
Anders Holst

Well, its of course always better to just complain and hope that someone else should fix it, but after my post above I decided to give it a try myself...

So after having fetched the sources from CVS and dived into the libdvb C-code, I realized that at least the simple solution was closer than expected: the repeat count of slow motion and the skip count of fast winding can be specified orthogonally to each other! Furthermore, this can be done directly from python with no need to modify the C-code.

This means that it is already possible from python to achieve e.g. 2x backwards speed by skipping 16 frames back and repeating this frame 8 times. As noted in my post above, this will not be a smooth rewind, but in discrete jumps, but at least it will give time to react.

Here is a patch to "Screens/InfoBarGenerics.py" (in the standard distribution, but it will hopefully work with some fuzz in the variants) which implements this. It adds -2x, -4x, and -8x speed, and also the "missing" x16 forward. It also adds a repeat count for x16 and higher, both forwards and backwards. At those speeds each frame may sometimes be from a new scene, and repeating each frame a few times makes winding at those speeds a less subliminal experience...

--- InfoBarGenerics.py.orig	2007-09-03 16:25:55.000000000 +0200
+++ InfoBarGenerics.py	2007-09-07 22:32:55.000000000 +0200
@@ -613,14 +613,16 @@
 	SEEK_STATE_FF_2X = (0, 2, 0, ">> 2x")
 	SEEK_STATE_FF_4X = (0, 4, 0, ">> 4x")
 	SEEK_STATE_FF_8X = (0, 8, 0, ">> 8x")
-	SEEK_STATE_FF_32X = (0, 32, 0, ">> 32x")
-	SEEK_STATE_FF_64X = (0, 64, 0, ">> 64x")
-	SEEK_STATE_FF_128X = (0, 128, 0, ">> 128x")
-
-	SEEK_STATE_BACK_16X = (0, -16, 0, "<< 16x")
-	SEEK_STATE_BACK_32X = (0, -32, 0, "<< 32x")
-	SEEK_STATE_BACK_64X = (0, -64, 0, "<< 64x")
-	SEEK_STATE_BACK_128X = (0, -128, 0, "<< 128x")
+	SEEK_STATE_FF_16X = (0, 48, 3, ">> 16x")
+	SEEK_STATE_FF_32X = (0, 96, 3, ">> 32x")
+	SEEK_STATE_FF_64X = (0, 192, 3, ">> 64x")
+	
+	SEEK_STATE_BACK_2X = (0, -16, 8, "<< 2x")
+	SEEK_STATE_BACK_4X = (0, -16, 4, "<< 4x")
+	SEEK_STATE_BACK_8X = (0, -24, 3, "<< 8x")
+	SEEK_STATE_BACK_16X = (0, -48, 3, "<< 16x")
+	SEEK_STATE_BACK_32X = (0, -96, 3, "<< 32x")
+	SEEK_STATE_BACK_64X = (0, -192, 3, "<< 64x")
 
 	SEEK_STATE_SM_HALF = (0, 0, 2, "/2")
 	SEEK_STATE_SM_QUARTER = (0, 0, 4, "/4")
@@ -795,39 +797,44 @@
 				self.SEEK_STATE_PAUSE: self.SEEK_STATE_SM_EIGHTH,
 				self.SEEK_STATE_FF_2X: self.SEEK_STATE_FF_4X,
 				self.SEEK_STATE_FF_4X: self.SEEK_STATE_FF_8X,
-				self.SEEK_STATE_FF_8X: self.SEEK_STATE_FF_32X,
+				self.SEEK_STATE_FF_8X: self.SEEK_STATE_FF_16X,
+				self.SEEK_STATE_FF_16X: self.SEEK_STATE_FF_32X,
 				self.SEEK_STATE_FF_32X: self.SEEK_STATE_FF_64X,
-				self.SEEK_STATE_FF_64X: self.SEEK_STATE_FF_128X,
-				self.SEEK_STATE_FF_128X: self.SEEK_STATE_FF_128X,
-				self.SEEK_STATE_BACK_16X: self.SEEK_STATE_PLAY,
+				self.SEEK_STATE_FF_64X: self.SEEK_STATE_FF_64X,
+				self.SEEK_STATE_BACK_2X: self.SEEK_STATE_PLAY,
+				self.SEEK_STATE_BACK_4X: self.SEEK_STATE_BACK_2X,
+				self.SEEK_STATE_BACK_8X: self.SEEK_STATE_BACK_4X,
+				self.SEEK_STATE_BACK_16X: self.SEEK_STATE_BACK_8X,
 				self.SEEK_STATE_BACK_32X: self.SEEK_STATE_BACK_16X,
 				self.SEEK_STATE_BACK_64X: self.SEEK_STATE_BACK_32X,
 				self.SEEK_STATE_BACK_128X: self.SEEK_STATE_BACK_64X,
 				self.SEEK_STATE_SM_HALF: self.SEEK_STATE_SM_HALF,
 				self.SEEK_STATE_SM_QUARTER: self.SEEK_STATE_SM_HALF,
 				self.SEEK_STATE_SM_EIGHTH: self.SEEK_STATE_SM_QUARTER,
-				self.SEEK_STATE_EOF: self.SEEK_STATE_EOF,
+				self.SEEK_STATE_EOF: self.SEEK_STATE_EOF
 			}
 		self.setSeekState(lookup[self.seekstate])
 
 	def seekBack(self):
 		lookup = {
-				self.SEEK_STATE_PLAY: self.SEEK_STATE_BACK_16X,
+				self.SEEK_STATE_PLAY: self.SEEK_STATE_BACK_2X,
 				self.SEEK_STATE_PAUSE: self.SEEK_STATE_PAUSE,
 				self.SEEK_STATE_FF_2X: self.SEEK_STATE_PLAY,
 				self.SEEK_STATE_FF_4X: self.SEEK_STATE_FF_2X,
 				self.SEEK_STATE_FF_8X: self.SEEK_STATE_FF_4X,
-				self.SEEK_STATE_FF_32X: self.SEEK_STATE_FF_8X,
+				self.SEEK_STATE_FF_16X: self.SEEK_STATE_FF_8X,
+				self.SEEK_STATE_FF_32X: self.SEEK_STATE_FF_16X,
 				self.SEEK_STATE_FF_64X: self.SEEK_STATE_FF_32X,
-				self.SEEK_STATE_FF_128X: self.SEEK_STATE_FF_64X,
+				self.SEEK_STATE_BACK_2X: self.SEEK_STATE_BACK_4X,
+				self.SEEK_STATE_BACK_4X: self.SEEK_STATE_BACK_8X,
+				self.SEEK_STATE_BACK_8X: self.SEEK_STATE_BACK_16X,
 				self.SEEK_STATE_BACK_16X: self.SEEK_STATE_BACK_32X,
 				self.SEEK_STATE_BACK_32X: self.SEEK_STATE_BACK_64X,
-				self.SEEK_STATE_BACK_64X: self.SEEK_STATE_BACK_128X,
-				self.SEEK_STATE_BACK_128X: self.SEEK_STATE_BACK_128X,
+				self.SEEK_STATE_BACK_64X: self.SEEK_STATE_BACK_64X,
 				self.SEEK_STATE_SM_HALF: self.SEEK_STATE_SM_QUARTER,
 				self.SEEK_STATE_SM_QUARTER: self.SEEK_STATE_SM_EIGHTH,
 				self.SEEK_STATE_SM_EIGHTH: self.SEEK_STATE_PAUSE,
-				self.SEEK_STATE_EOF: self.SEEK_STATE_BACK_16X,
+				self.SEEK_STATE_EOF: self.SEEK_STATE_BACK_2X
 			}
 		self.setSeekState(lookup[self.seekstate])

You also need a small fix to "Screens/MediaPlayer.py" to stop it from refering to individual speed states, since these will change when you start experimenting with this.

--- MediaPlayer.py.orig	2007-07-22 20:27:34.000000000 +0200
+++ MediaPlayer.py	2007-09-07 22:30:37.000000000 +0200
@@ -643,17 +643,9 @@
 			self.playlist.pauseFile()
 		elif self.seekstate == self.SEEK_STATE_PLAY:
 			self.playlist.playFile()
-		elif self.seekstate in ( self.SEEK_STATE_FF_2X,
-								 self.SEEK_STATE_FF_4X,
-								 self.SEEK_STATE_FF_8X,
-								 self.SEEK_STATE_FF_32X,
-								 self.SEEK_STATE_FF_64X,
-								 self.SEEK_STATE_FF_128X):
+		elif self.seekstate[1] > 0:
 			self.playlist.forwardFile()
-		elif self.seekstate in ( self.SEEK_STATE_BACK_16X,
-								 self.SEEK_STATE_BACK_32X,
-								 self.SEEK_STATE_BACK_64X,
-								 self.SEEK_STATE_BACK_128X,):
+		elif self.seekstate[1] < 0:
 			self.playlist.rewindFile()
 
 	def pauseEntry(self):

This is just an example patch - you can play around with it in many ways. For example, as suggested earlier in the thread, the first press on back/forward could start at a higher speed than 2x (and further presses will climb up or down in speed). Just modify the end of the two lines starting with "self.SEEK_STATE_PLAY:" by inserting the state with the preferred initial speed.

Some notes:
As mentioned in my previous post, the backwards speed is not always accurate. "-16x" is actually closer to -30x for many services. In the same way, after the above modification "-2x" may still be closer to -4x in reality.

I also tried, as MacDisein above, using "smooth" backward rewind in lower speeds than 16x. What happens can be described as "sawtooth" playback, i.e. it jumps one GOP backwards and plays it up forward in the specified speed, then jumps another GOP backwards and plays it up, and so on. This is most pronounced at lower speeds, which gives a really shaky impression. At -8x it is not so pronounced, but it still exist. This may explain the confusion in the thread above of wheither -8x or -16x is the lowest acceptable "smooth" speed. However, then I noticed a slight "sawtooth" behavior also at -16x (even when the typical GOP size is less than 16). This of course gets easier to see when the speed is slowed down by repeating frames. Although annoying for a perfectionist, it is however fortunately not very disturbing, and you probably woudn't notice if you didn't know it was there (OK, sorry for mentioning it...).

Best Regards
Anders Holst

There has been some requests for .ipk-versions of the plugins instead of tar.bz2. They are included here.

Best Regards
Anders Holst

Maybe I stick my nose out too far now, but I think that this fast rewind issue is important and should not be dismissed just because it is "hard" to implement. Direct jumps a number of seconds backwards or forwards is of course also useful but not the same thing. As fast rewind works today it is almost useless; no one can react fast enough to stop in time. It may be hard to fix but probably not impossible.

One simple solution could be to slow it down by displaying the same frames two, four, or eight times. It would not be a smooth rewind, but at least would give people time to react.

A more complicated solution would be to go 16 frames back and then forward from there to the correct position, buffering suitable frames on the way. With a brute force method one could buffer all sixteen frames and play them up backwards. A more clever method would require less buffers and can be done without having to unpack several frames per shown frame, if memory and/or computation time is critical.

Such a more complicated solution would also make possible single stepping both forwards and backwards, which would make it much easier to e.g. find appropriate cut points in the Cutlist editor.

By the way, while 8x forward is quite acceptable and possible to follow, the so called x16 backwards seemed unreasonably much faster, so I timed it. The speed turned out to depend on the service. Some programs made 24 minutes backwards in about 95 second, meaning approximate 15x, whereas other services made 24 minutes backwards in 48 seconds, which in my opinion is closer to 30x. Yet others are in between this. (I carefully checked that the legend showed "<< 16x" in the upper corner of the picture in all cases.) Although this behavior may again have been easier to implement than "precisely 16x", I would consider this to be a bug!

Best Regards
Anders Holst
(soon nose-less)

Thanks for the example python code some of you sent me. I have now finally managed to turn my code into Enigma2 modules with menu interfaces:
MovieCut-1.0 to apply the cuts and MovieRetitle-1.0 to rename movies.
I have posted them in the thread Code to perform the movie cuts on DM7025.

Best Regards
Anders Holst

I have now managed to wrap my C-code in real python plugins with menu interfaces. There are two plugins that work well together (but can be installed and used independently):
MovieCut-1.0 is to apply Cutlist editor cuts to the movie.
MovieRetitle-1.0 is to change the filename, title, and description of a movie.
Both places themselves in the movie list menu, next to the Cutlist editor.

Thanks for the helpful code examples some of you sent me. Still, it was not an easy task to try to learn python through the enigma code: in the beginning any small modification I tried of the code to make it work the way I wanted either caused enigma to crash, or it didn't compile at all with no way to find out why. However, after endless late nights and exactly 179 enigma crashes, these modules are the results.

Attached are the two modules plus their readme files.

Best Regards
Anders Holst

Sorry for crashing into an almost resolved thread like this, but for what its worth I may have another solution.

Zitat

Originally posted by BushWhacker
Another request: A simple way to cut a recording. I always record 15 minutes before and 30 minutes after (Veronica is bad in timing ) and I would like to remove the crap before and after.

Check out my "mcut" package (Code to perform the movie cuts on DM7025). It can be used together with the cutlist editor, or by itself, to actually cut off the unwanted parts of the ts file, which may save a lot of space on the disk in your case.

Unfortunately there is no menu interface to it (yet), so the commands in the package have to be run from the shell in the dreambox.

Zitat

Originally posted by BushWhacker
What I really like to do is change the name and metadata of recordings.
I have a dream-keyboard, so it would be very handy if I can use it for the renaming.

When experimenting with "mcut" I also found that I sometimes needed to change the title and description in the meta file. For example, sometimes I record consecutive movies to the same file. With mcut I can easily separate them again, but then I must of course set the
titles right.

So I wrote a C hack to do it. (I realize now that it could have been done in python, but since I too don't know python this was faster for me.) It was not included in the mcut package above since I hadn't anticipated any broad demand for it. Probably I should have included it after all when I think of it.

The program "mtitle" takes the ts file name, the new title, and optionally a new description, and modifies the corresponding meta file. Thus it should work also when there is no title or description initially in the meta file.

The drawback is of course that this too has to be run from the shell. So it is not the nice interactive dialog that one would like. Once I learn python, etc etc... (Maybe I will look at gutemine's code to see if I can steal the interaction parts, but don't hold your breath.)

Best Regards
Anders Holst

While developing "mcut" (see the post Perform movie cuts on DM7025) I discovered a few strange behaviors which may be due to a bug in how the .ap files are used. The .ap files apparently contain a mapping between file positions in bytes and time stamps in the movie. The time stamps are typically about one or one half second apart depending on the recorded service. This mapping is used among other things when stepping backwards through a movie. That is, pausing and then pressing fast-backwards, always jumps to such a point listed in the .ap file. For lack of a better name I will in the following call the sequence of a movie between two consecutive time stamps in the .ap file a "chunk".

I noted the following, maybe seemingly unrelated details:

• Stepping backwards through the movie jumps over two chunks at a time, i.e. if the chunks are half a second long the jumps are one second long, and if the chunks are one second the jumps are two seconds long. The intention is probably to be able to jump over one chunk at a time.
  

  
  

• When using the cutlist editor, the actual cuts are offset somewhat from where they are set. For example, carefully stepping as above to the best position for a cut, causes the actual cut to be positioned some second later (presumably one chunk length) than what was intended.
  

  
  

• When looking at the movie list, the indicated times of the movies seem always to be about one second too short. I.e a one hour recording is indicated as 59:59 long. When actually cutting out exactly two minutes with "mcut", which I know will add some extra margin on both sides and thus be some part of a second longer than two minutes, it is indicated as 1.59 long. Perhaps the last "chunk" is not counted?
  

  
  

• When diving into the representations in the various files (when writing "mcut") I noted that the time stamps in the .ap file were slightly offset from the time stamps in the mpeg stream at the corresponding position in the file.

The last observation made me wonder if the time stamps in the .ap file was unintentionally shifted one step, and if this would cause one or more of the first three oservations.. So since I was already able to parse and process the .ap file I made an experiment: I shifted all timestamps in the .ap file one step to see what happened. The results were mixed:

• Stepping backwards indeed now jumped only one chunk at a time, so for this the fix was successful.
  

  
  

• Unfortunately for the cutlist editor the offset between intended cut and actual cut increased by one chunk length rather than decrease as I had hoped.
  

  
  

• The lengths in the movie list was probably not affected, or rather the movie now seemed two seconds shorter than it actually was, but this was expected since I loose one chunk when I shift everything in the .ap file.

So what can one say from this? Probably the .ap file is correct after all, but the values in it are used in the wrong way (or in two different wrong ways) both when stepping backwards and by the cutlist editor. The short movie lenths are probably unrelated and maybe due to unfortunate roundoff (or missing the last chunk and then truncating the length rather than rounding).

Maybe these observations will help someone to rectify these bugs?

(These effects were observed with Enigma2 version=20070109. "Hopefully" I have not made a fool of myself by posting a bug report for bugs that are already fixed...)

Best Regards
Anders Holst

I am also interested in the porting of DreamDVD and Burn2DVD to DM7025.

I have installed the gcc development environment on my DM7025, so if it is mainly a matter of compiling the code on that platform I will be happy to help. If there are large differences in the relevant drivers of 7000/7020 and 7025 then it may be more tricky and I can't promise anything...

We are almost there now it seems, to the goal which just a few months ago seemed impossible: the possibility to cut and then burn a movie just by simple menu selections on the dreambox, without the need to transfer it to a PC, and then being able to watch the resulting DVD through the dreambox again.

Best Regards
Anders Holst

I have written a C code hack to actually perform the cuts specified with the cut list editor of DM7025.

The hack was inspired and guided by the similar package "moviecutter" by Georges. However, you need not wait over the night but it can run in the background as you keep watching on your dreambox, and a typical movie takes about 15 minutes to process.

What is not yet done is to provide a menu alternative "Apply cuts" next to the "Cutlist editor" alternative in the movie menu. Python is not my language though, so I may need some help with this. Currently you have to log in to the dreambox and run the program from the shell.

Another drawback is that when a section is removed within a movie the picture freezes and breaks up briefly at the cut (just as it does when you look directly at a movie with cutlist editor cuts). I guess that this means that I fail to hit the GOP-boundaries (which confuses me because I really tried to). Cutting off the start and end of a movie works without such artifacts though.

There is actually a set of related programs that are provided:

mcut <filename>
Copies the sections that are not removed according the the cut list editor marks to a new file with " cut" appended to its name.

mcutarg <filename> <starttime 1> <endtime 1> [<starttime 2> <endtime 2> ...]
Copies the sections given as arguments to a new file with " cut" appended to its name. The times are given as <hour:min:sec> as counted from the beginning of the movie, and note that the section between a start time and an end time is *retained* and not removed (i.e. opposite to the cutlist editor semantics where the given sections are removed.)

lscut <filename>
Displays the mark times as set by the cutlist editor (if you by some reason don't want to start the cutlist editor to check on screen).

chcut <filename> <starttime 1> <endtime 1> [<starttime 2> <endtime 2> ...]
Sets the cut marks for the file without using the cutlist editor according to the specified start and end times. As above, the times are given as <hour:min:sec> as counted from the beginning of the movie, and note that the section between a start time and an end time is *retained* and not removed (i.e. opposite to the cutlist editor semantics where the given sections are removed.)

mrename <filename> <new filename>
Renames the movie by renaming all the files involved. Typically, after having cut a movie you may want to delete the original and rename the result to the original name. This can of course be performed as well by a number of "mv" commands at the shell, but the file names are long and there are many files involved for each movie...

All movie filenames can be given either with or without the ".ts" suffix, and all other suffixes are added by the programs where needed.

Below are only the binaries for DM7025 included. I guess that some of the programs could be useful even without the cutlist editor (which I understand is only provided on DM7025) although I have no access to other models so I have not been able to verify that it works. If
someone likes to try to compile them on another dreambox model, please contact me and I'll send you the source code. (Or if you like the source code for any reason at all, since it is under GPL.)

Best Regards
Anders Holst