Beiträge von aholst

    myname70 wrote:

    Zitat

    If this MovieCut version wil work on DM800 as well?


    It will work partially on DM800. There are two exceptions:
    * There may be flickering between cuts on DM800. (It is finetuned for the drivers of DM7025, and those on DM800 are different.)
    * It will not work for HD recordings. (There is currently no warning if you try, but the result will be equally large or larger than the original and unviewable.)


    I have been trying to investigate a little the last few days, to see if it is possible to solve these things, but it was harder than expected, and I can't guarantee that I succeed. I will let you know if there is any progress.


    Best Regards
    Anders Holst

    ecky2 wrote:

    Zitat

    And it should also not be config.movielist.last_videodir.value .
    There is no releation between last videodir and next timerdir.


    Now I'm not sure I understand what you mean.


    The above line relates only to instant recordings. My design, bad or good, was to use last_timer_videodir when creating new timer entries, but last_videodir when starting instant recordings, as I tried to motivate above.


    I certainly agree that with suitable effort it is possible to do much better, i.e. full configuration of the behavior here, but until then I think that my proposed behavior is at least better than the one that has, for unknown reasons (although probably someone who also didn't like the proposed solution and tried to make it better but inadvertently ruined it), appeared in boxmans image.


    Best Regards
    Anders Holst

    Hello


    I have written two tools which may be useful in connection to MovieCut/mcut. Unfortunately they are currently only callable from the shell, i.e. using telnet or ssh.


    Both programs and their source code are included in the attached tar file. Brief descriptions are below.


    Best Regards
    Anders Holst



    mreconstructap


    In case the .ap-file is lost, or corrupted, or nonexisted because the movie comes from another platform, then the program "mreconstructap" can construct a new .ap-file corresponding to the movie. The .ap-file is used to map between time and position in the movie file, and is required to be able to use MovieCut/mcut.


    Just call it like:
    > mreconstructap movie.ts
    and it will replace the old movie.ts.ap.



    msplice


    With this program you can append movies or movie parts (from the same service), or split them apart again, or merge parts of movies in another order (for whetever use that may be).


    In more detail, msplice considers a movie as consisting of a number of parts, separated by "discontinuities" in the recorded time. Such discontinuities appear e.g. at the cut positions of MovieCut or mcut, but also sometimes when there are errors in the stream. msplice can split up one or several movies at those discontinuities and merge the parts together again in any order. In doing so it will try to clean up the cuts/discontinuities to avoid flickering and breaking up of the picture. (Note however, that if parts from several movies are appended they need to be from the same service, or the result will be unusable. Also, if you happen to use the same part twice, the dreambox will be confused and jumping and winding will not work.)


    Some examples of how to use it:


    Appending:


    If you have imported a movie in several parts from e.g. DM7000 or DM7020 and want them as one chunk, or if Enigma2 crashed and left an ongoing recording in two parts, then you can merge them as:
    > msplice -o resulting_movie.ts part1.ts part2.ts part3.ts
    Note however that you must have .ap-files for all parts, so if they come from an Enigma1 model you must use mreconstructap first on each part.


    Splitting:


    If you have merged several short movies with msplice, and want to undo that, then you can use the -s (for "split") flag:
    > msplice -s movie.ts
    The parts will be separated into movie_sec001.ts, movie_sec002.ts, etc. Note that this will not work if the merged parts are perfectly adjacent, as for several parts of a movie from Enigma1. Then there are no discontinuities any more between the parts. If you need to split it up again in smaller chunks without having discontinuities in the movie, you should use mcut instead.


    Checking and repairing:


    With the first version of mcut, the cuts vere not "clean", i.e. the picture flickered and broke up for a few frames. With msplice you can repair such previously cut movies, to get rid of the flickering. The price to pay is loss of aproximately one GOP around the cut.


    To check how many cuts a movie contains, and whether they are "clean", use the -l (for "list") flag:
    > msplice -l movie.ts
    It checks the file (without modifying it) and reports the length of each part, and tells if any cut is not clean. If there are unclean cuts in the movie, then the -r (for "repair") flag can be used to clean it up:
    > msplice -r movie.ts
    Note that this will overwrite the original movie. If you want a cleaned copy instead, use the normal form of msplice instead:
    > msplice -o cleaned_movie.ts movie.ts


    Advanced use:


    If the task involves splitting up several movies and then merge selected parts of them, this can be done in one step:
    > msplice -o resulting_movie.ts movie1.ts:1,3 movie2.ts:4-6 movie3.ts:3,2,1
    where the numbers after the colon indicate which parts of each movie to use. If the movie names are long, and each movie has to occur at several positions in the list, then aliases can be used:
    > msplice -o resulting_movie.ts A=movie1.ts B=movie2.ts A:1 B:2 A:3-5
    where A and B can be any strings not containing colons or equal signs.


    This advanced form may not be so often useful in practice but it was fun to implement...

    murray wrote:

    Zitat

    mit was schneidest du, die Box kann das doch bis heute gar nicht?


    kenatonline wrote:

    Zitat

    Nur wenn beim Schneiden auch die *.ap-Datei angepasst wuerde, haettest Du ein perfektes Ergebnis.
    Ich kenne allerdings kein Programm, was das koennte.


    Have you checked out my plugin MovieCut?


    Today I have also, in the same thread as MovieCut, released some useful tools. One of them, mreconstructap, can reconstruct the .ap-file if it is missing or corrupt (as for example if you have managed to cut the movie with another program which doesn't adapt the .ap-file). The program can currently only be run from the shell (i.e. telnet or ssh).


    Best Regards
    Anders Holst

    Zitat

    I think this is a bug, as you do not know this behaviour...


    Yes indeed! Then I can understand everyones indignation!


    But it is not the way it behaves here. Which image do you use? Or more specifically (but this is a long shot), has anyone had this in another image than Boxman (which was mentioned by frankd)?


    Check line 1411 (or therearound depending on the version) of InfoBarGenerics.py, it should read:

    Zitat

    recording = RecordTimerEntry(serviceref, begin, end, name, description, eventid, dirname = config.movielist.last_videodir.value)

    The last argument is the location, and it should not be last_timer_videodir.


    When it comes to autotimer, I guess that yet another principle should be used. I have not used it myself yet, but isn't the best solution to specify the location in the same dialog as the autotimer pattern? The movie category is probably known when the pattern is constructed. And the default for that field in the dialog box could then be given by a new variable last_autotimer_videodir.


    Best Regards
    Anders Holst

    ralfK wrote:

    Zitat

    Das ganze müsste von aholst sein.


    Yes, I guess that the current solution is by my design: The suggested location in new timers is the same as for the last created timer (or last edited timer if the location was modified), whereas instead the location for instant recordings is the "current" location as shown when pressing "video".


    I agree that the "correct solution" would be to make this configurable, for example by letting the user select whether to use the "default location" (for now always "/hdd/movie", but this should be configurable too), the current location, the last set timer location, or any fixed location of the users choice.


    However, I wanted to get the code out (i.e. my part of this joint project with ritzMo and ralfK) reasonably fast, because it had taken too long already, and if I had embarked on the new task of adding full configurability I would not be able to make it before the end of the summer, after which everything would slow down considerably. So I thought hard about the best solution here that would be make it mostly right for most people.


    The rationale is this: Two basic scenarios for usage of a location specification are that 1) a different location is specified because /hdd is full, or 2) locations are selected as a means to organize movies. The defaults should be reasonable in both those scenarios. When you create a new timer entry, the initial location value is only a "default suggestion" that the user may easily change, so here it is not so critical. Nevertheless I figured that a good guess would be the same location as was used the last time a timer was created or edited. In case the standard location is full, all created timers is likely to have the same new location. If not, then maybe one category of movies is be the most common, and selecting the same as last time will then be correct in most cases. If all categories are equally common, then there is no better way to guess the loaction anyway.


    But for instant recordings, then the user has no way of specifying the location when the recording is started, and the user is probably in a hurry if the movie has just started, so a new dialog box asking for location and stuff is not so convenient. And when the recording is started, how should the user know in which location it ended up after all? The solution is to put the movie in the first place the user will look when searching for it, i.e. the location that will show on the first press of "video". This also gives the means to specify the location if really needed - before starting the recording just change the location as usual with two presses on "video" and select the suitable bookmark.


    So there was a rationale that seemed reasonable at the time - but certainly different people have different preferences, so making this configurable is the best solution. Things may be a little slow now for me however, so if someone feels tempted to start at it, you're welcome...



    But then I get a little confused:


    ecky2 says:

    Zitat

    D.h. die Aufnahmen, die über die Rote Taste gestartet werden, landen im Pfad des zuletzt gewählten Ordners, aus welchem eine Aufnahme abgespielt wurde.

    Yes, this is exactly as I describe it above.


    But then frankd says:

    Zitat

    Auch ich finde es sehr unpraktisch, dass die Auswahl eines anderen Speicherorts für eine Aufnahme nun gemerkt wird und von da aus weitere Aufnahmen immer dort landen.
    ...
    Jetzt muß ich erst einen x-beliebigen Timer wieder auf hdd/movie erstellen, damit alle weiteren Timer, auch die Sofortaufnahmen etc. wieder dort landen, wo sie ja auch hin sollen.

    But this is one of the consequences I wanted to avoid by the solution described above! So what is going on here? I admit that it was a while now, and I have not checked out the most recent CVS, but I don't think it has changed since I touched it. Are you claiming that the last set timer location is used for instant recordings, rather than the current location as selected by "video"*2 ?


    Best Regards
    Anders Holst

    I think you should mount it under /media/hdd, or under /media/usb if you already have an internal disk on /media/hdd. Then it will be recognized by Enigma and show up under List of Devices in the LocationBox (as Harddisk or USB Stick respectively).


    Clearly there is something that doesn't work yet with the automount stuff. When I tried here, the automount program only seems to put a link to the device under /autofs/, whereas HarddiskManager and FileList happily assumes that they are actual directories and includes them in the directory listing. Maybe that's what caused the crash. I don't think these entries into /autofs/ should be shown in the file list at all, but I'm not familiar enough with automount and how the hotswapable stuff is supposed to work, so I leave it for someone else to make the patch. Until then, just don't use these entries...


    Best Regards
    Anders Holst

    The above version of MovieCut, 1.2, requires the location patches that came in place 2008-06-26 (I wrote 28th above, that was slightly wrong I see now). Still, many people may have images based on versions of Enigma2 before that date but still after the skin changes on 2008-04-14.


    To make MovieCut available to them, I have made a minor "backport" of the plugin, intended for the Enigma2 2.5 branch between 2008-04-14 and 2008-06-26. The location support is "crippled" back to the pre-26th-june level, but otherwise everything should be the same in the plugin.


    Best Regards
    Anders Holst

    The above version of MovieRetitle, 1.2, requires the location patches that came in place 2008-06-26 (I wrote 28th above, that was slightly wrong I see now). Still, many people may have images based on versions of Enigma2 before that date but still after the skin changes on 2008-04-14.


    To make MovieRetitle available to them, I have made a minor "backport" of the plugin, intended for the Enigma2 2.5 branch between 2008-04-14 and 2008-06-26. The location support is "crippled" back to the pre-26th-june level, but otherwise everything should be the same in the plugin.


    Best Regards
    Anders Holst

    Aha, now I see what you mean!


    "mcut" *is* included in the CVS version, but *not* in the ipk and tar.bz2 attached above!


    That was a pure omission. Sorry! New versions substituted above, so now they should work.


    Best Regards
    Anders Holst

    OoZooN wrote:

    Zitat

    is it a bug or a feature, that in the cvs version of moviecut the mcut binary is not shipped with the plugin? it's located in the package enigma2-plugins, but there is no packet depend from the moviecut ipk to enigma2-plugins


    This is probably because this is my first attempt to upload things to enigma2-plugins, and I don't know of any other way of doing it.


    But are you sure it is not included? Look again in Plugins/Extensions/MovieCut/bin/.


    It all seems to be a mess. The practice seem to be to *not* include configuration files or binaries and such in the plugin ipk file, but rather collect them in the global enigma2-plugins ipk file. I wasn't aware of this practice when I wrote the control file, and even if I were I wouldn't know exactly how to describe the dependency to get the appropriate version of the enigma2-plugins package (i.e of the same date as the moviecut package). I assume that if I added the dependency, then everytime someone downloaded the moviecut ipk from the server they would automatically also receive the global enigma2-plugins package? But this also contains several configuration files for other plugins (not a good idea it seems), which means that those configuration files would be overwritten every time someone downloads my package!


    So I wanted the binary included, and made an ugly fix to fool the automatic package builder to add it there (in addition to in the global package). But then it was not recognized as a binary file, so then I added an even uglier fix to make sure it was executable when the package is first loaded.


    Well, thats the long story. I believe it works, but it certainly is not the right way of doing it. If anyone knows the right way, without the adverse effects mentioned above, I would be grateful to know it.


    Best Regards
    Anders Holst

    There is a new version of the MovieRetitle plugin available.


    It is now possible to move to another location. If the other location is on another device, moving will be performed in the background and a notification given when moving is finished. The old movie will not disappear from the movie list until then. It is possible to request moving more movies before the first one has finished, but they will be queued up and moved after each other not the stress the external media too much.


    This version is adapted to the skin changes of 2008-04-14 and requires the "location stuff" changes of 2008-06-28.


    The version does *not* include the patch by Tode to handle extended description, since I'm still not sure about the best practice here, and there seem to be differences between countries. But I welcome Tode to provide a patched version of this version too.


    Included below are ipk and tar.bz2 files. This version can also be downloaded from the plugin menu if you use the experimental feed.


    Best Regards
    Anders Holst

    There is a new version of MovieCut available.
    * It is adapted to the skin changes of 2008-04-14.
    * It includes the possibility to cut into another location, using the location changes of 2008-06-28 (in the 2.5 branch of Enigma2, which means that this branch is required).
    * It uses eConsoleAppContainer instead of spawnv/waitpid to launch "mcut".
    Hopefully this version solves both the problems experienced by moveq and by DLH007 and pucco.
    Included below are ipk and tar.bz2 files. This version can also be downloaded from the plugin menu if you use the experimental feed.


    Best Regards
    Anders Holst

    I know there is a superfluous Screen class in the beginning, (one of the things removed in the next version), but that Screen is never used, and the openWithCallback that you pressumably refer to opens the initial Screen which is a ChoiceBox. Therefore I suspect that this is not the real reason for the crsh. Especially since it works here. If it were wrong it would probably crash every time and everywhere.


    (Thanks for the report, all help to weed out bugs is of course appreciated. But if you want me to track this further I would really need a crash log... But I suggest you wait until the new version is out.)


    Anders

    moveq wrote:

    Zitat

    This plugin is calling session.open() from __init__() and it makes it crash with a "modal mismatch" quite often...


    Yor report is quite vague (no crash-log, no mention of whether it crashes in the beginning or end or at a certain dialog), and I don't manage to repeat the problem here, and I also see no potential problem with calling open at that place.


    So I can only speculate: For example, the Suomipoeka plugin is known to have this destructive effect on some plugins (among them MovieCut), apparently because it tries to close the menu the plugin was started from, right after starting it. I have not followed up exactly what happens.


    Anyway, a new version of MovieCut is on its way, adapted to recent enigma2 changes, and with some luck it will also solve your problem.


    Best Regards
    Anders Holst

    I am not familiar with the .cutlist format. How are the cut points stored?


    In the .ts.cuts files it is stored as time from start of the movie (in parts of 1/90000 seconds). If for example the .cutlist stores them as byte positions of the file, that would give the symptom you describe. If so, the table stored in the .ts.ap file is the one to get the correct conversion between byte position and time.


    Best Regards
    Anders Holst

    janza wrote:

    Zitat

    I was wondering whether it would be possible to run mcut on (linux) PC?


    Sure, I can send you the C++ code if you send me an email. (I can't send attachments through the board email facility, so this is the easiest way.)


    However, on a linux PC with X11 as window system there are several alternative and more powerful tools to cut your movie. I think one is called "dvbcut", but there are probably many more out there.


    Best Regards
    Anders Holst

    This certainly seems like an annoying bug, but I am not able to reproduce it here.


    Does it happen every time or just now and then?


    To figure out where it hangs, I would need your help. I have attached a version of the plugin with some debug output. Could you please try this:
    * Replace the old /usr/lib/enigma2/python/Plugins/Extensions/MovieCut/plugin.py with this one (which is called .txt to make it attachable, but it is just .py)
    * Log in to a shell (with e.g. telnet or ssh)
    * Stop the old enigma2 by giving the command "init 4"
    * Start enigma2 again with the command "/bin/sh /usr/bin/enigma2.sh 2> /hdd/enigma2_logfile"
    * Do the steps you usually do to cut a movie, and when it seems done (from e.g. the disk spinning down as you say) try to cut another one.
    * Stop enigma2 either by "Restart GUI" from the menu, or Ctrl-C in the shell.
    * If you managed to provoke the bug, send me the resulting log file /hdd/enigma2_logfile (per email, it is uninteresting for the forum). Otherwise you have to try again from the fourth point above.
    * Restart enigma2 in normal mode again by the command "init 3"


    Hopefully this logfile will show where it hangs.


    Best Regards
    Anders Holst


    (Edit: OK, I'm aware of the skin changes, and this version do not take them into account, but just dont use the fourth alternative "advanced cut parameter settings"...)

    Hello


    I have found and fixed the bug that the initial winding speeds is restored to 2x every time. The patch is below. I will submit it to the CVS, but meanwhile you can try it yourself.


    I could not repeat the problem with the configurable jump keys - they work perfectly here (in the CVS version of Enigma2 from 080502). However, the symptom you have is typical for a movie with a missing or damaged .ap file. Maybe you could try with another movie from another provider.


    Best Regards
    Anders Holst