Dear Rüdinger Thanks for the reply.
Am Montag, den 29.08.2011, 17:29 +0200 schrieb Ruediger Rolf: > Your pipelines do not work. Please sent the last section of your Capture > agent Config file > (org.opencastproject.capture.ConfigurationManager.properties). I think > the configuration ist broken. I attached the CA config file to the email. Here I have to mention that for a test capture on the CA everything works fine. In the CA log there appears an ERROR when the agents tries to push his capabilities to the core server. Perhaps this is the issue?! It is strange that the status can be pushed but the capabilities not: 11:32:55 INFO (AgentStateJob:194) - #6 - State push org.opencastproject.capture.impl.jobs.AgentStateJob@3849ca75 to http://matterhorn.cs.unibas.ch/capture-admin/agents/unibasMatterhorn was successful. 11:32:55 INFO (AgentCapabilitiesJob:115) - #6 - Capabilities push to http://matterhorn.cs.unibas.ch/capture-admin/agents/unibasMatterhorn/capabilities failed with code 405. > > I'm still confused that mediainspection the zip workflow fails... Do > you have installed the 3rd party tools successful? Can you call > mediainfo from the command line on the server? > I did not install anything with 3rd party tools on the centOS, but gzip, bzip2 and java was pre installed. The only thing I did was installing gstreamer and ffmpeg (is this 3rd party?). Is this enough or should there be more 3rd party tools? Unfortunately I have no idea what a top level scrip is and where I can find ./menu3p mentioned in this readme file: http://opencast.jira.com/svn/MH/tags/1.1.0/docs/scripts/3rd_party/README.txt Is it necessary to execute it?! > Why don't you change the working directory to a permanent directory > (/tmp/opencast will be deleted with every restart of the server) and > make sure that your matterhorn user has the right to write in the new > content directory. I changed the working directory variable on the core server from org.opencastproject.storage.dir=${java.io.tmpdir}/opencast to /opt/matterhorn/cache/opencast now and gave all rights for the matterhorn user. g matt > > Rüdiger > > > > > Am 29.08.2011 13:13, schrieb stefan braun: > > Dear Rolf > > > > Thanks for your reply. > > > > I use a core server running on centOS (the all-in-one Linux server) and > > a CA running on ubuntu 10.10. Both server and CA are version 1.1. What > > do you mean with the content directory? The /tmp/opencast directory > > where the media-files are stored? > > > > I found out now that if I try to schedule a new recording job on the > > server for the capture agent, then there is a pipeline error. That is > > why my media files have zero size and perhaps the reason why the files > > can not be inspected?! The test on the CA works fine: vga, dv and alsa > > audio can be recorded and listened/watched later. How could I fix a > > pipeline error? > > > > Here the log of my last recording schedule (attached to the email) > >
# Please note that the intervals and times specified in this file are in *seconds* # The URL of the central core. This assumes that all services are running on the same machine. # The above assumption might not be correct. If so then replace the appropriate keys below with your urls. org.opencastproject.capture.core.url=http://matterhorn.cs.unibas.ch #NOT http://localhost:8080 ### Required variables start here (the agent will behave oddly without them) ### # The URL of the caching directory under the root directory capture.filesystem.cache.url=${org.opencastproject.storage.dir}/cache/ # The URL of the volatile directory under the root directory capture.filesystem.volatile.url=${org.opencastproject.storage.dir}/volatile/ # The root URL where the captures should be stored prior to ingest capture.filesystem.cache.capture.url=${capture.filesystem.cache.url}/captures/ # Image that should be displayed, if no vga-source is connected to the epiphan vga2usb. If no image is set some color-bars are displayed # capture.fallback.png=images/novideo.png # The remote URL where the capture schedule should be retrieved capture.schedule.remote.endpoint.url=${org.opencastproject.capture.core.url}/scheduler/${capture.agent.name}/calendar # The time in minutes between attempts to fetch updated calendar data capture.schedule.remote.polling.interval=5 # The local URL of the cached copy of the capture schedule capture.schedule.cache.url=${capture.filesystem.cache.url}/schedule.ics # Location of a centralized configuration file capture.config.remote.endpoint.url= # The time in seconds to wait between updating the local copy of the configuration capture.config.remote.polling.interval=600 # The file to cache the server config, if any capture.config.cache.url=${capture.filesystem.cache.url}/capture.properties # The name of the agent capture.agent.name=unibasMatterhorn # The URL of the remote state service capture.agent.state.remote.endpoint.url=${org.opencastproject.capture.core.url}/capture-admin/agents # The time in seconds between attempts to push the agent's state to the state service capture.agent.state.remote.polling.interval=10 # The time in seconds between attempts to push the agent's capabilities to the state service capture.agent.capabilities.remote.polling.interval=10 # The URL of the remote recording state service capture.recording.state.remote.endpoint.url=${org.opencastproject.capture.core.url}/capture-admin/recordings # Number of attempts the capture agent will attempt to ingest before waiting on the next attempt. **/ capture.ingest.retry.limit=5 # The length of time to wait between trying to retry to ingest. capture.ingest.retry.interval=300 # The length of time to wait until trying to ingest again after failing the number of times in INGEST_RETRY_LIMIT. capture.ingest.pause.time=3600 # if retry hard limit is true, the most retries attempted will be capture.ingest.retry.limit. The retry pause time will be ignored. capture.ingest.retry.hard.limit=false # The maximum length of a capture, defaults to 8 hours (28800 seconds) capture.max.length=28800 # The maximum length of time in seconds to wait before force killing a capture when stopping a recording capture.recording.shutdown.timeout=60 # The default time in seconds between subsequent executions of the capture cleaner capture.cleaner.interval=3600 # The default minimum available disk space, under which recordings are erased from the system # IN BYTES # NOTE: This diskspace value does *NOT* take the reserved disk space for the root user into account # PLEASE: Set this value to more than the reserved space on disk (typically 5%) otherwise the minimum disk space # checks will not function because there will appear to be enough disk even if you cannot write to the 5% capture.cleaner.mindiskspace=536870912 # The default maximum time (in days) a recording should be kept if there's enough disk space available capture.cleaner.maxarchivaldays=30 # confidence monitoring outputs images to this directory capture.confidence.video.location=${org.opencastproject.storage.dir}/volatile/ # enable/disable confidence monitoring capture.confidence.enable=false # enable/disable timestamps on confidence images capture.confidence.debug=false #Controls the behaviour of the agent when two scheduled events overlap or are within X of one another. #Setting this value to true will cause the cronologically second event to be dropped from the schedule. #Any other setting will have the agent shorten the second event to fit. #Note that if the length drops below the minimum capture length then the capture will not be scheduled. capture.schedule.event.drop=false #The length of time to require between capture events. Specified in minutes. #Note that this is a limitation of your hardware: It takes a certain length of time for the hardware #to stop and then be ready to capture again. Setting this to less than 1 will *not* make this happen #any faster, and will in fact cause you more problems when the agent tries to start a second capture #while the first is still in progress. capture.schedule.event.buffertime=1 ### Required variables end here ### ### MH-4493 Properties for Felix error watch process ### # The following properties will define how to handle Felix is it does not stay # running indefinitely. If, for whatever reason, Felix crashes it will not # restart by default. The script watch_felix.sh was created to be used in # combination with crontab as a safeguard for Felix. # Comma-delimited list of email addresses to send notification of failure to capture.error.emails= # The SMTP host to send the mail from (Default: localhost) capture.error.smtp= # The SMTP user to send the message from (Default: current user) capture.error.smtp.user= # The password for the user (Default: no password necessary) capture.error.smtp.password= # The subject and message of the email, respectively. Use %date to put a # timestamp in the subject/message and use %hostname to put the hostname in. capture.error.subject="%hostname capture agent started at %date" capture.error.messagebody="Capture agent was not running, and was just started." ### Capture device definitions ### # The following lines create three example inputs for the capture agent, often # refered to as the "mock agent" for testing purposes. Each input consists of: # 1: The source, in this case a file which is listed in the project pom.xml # as a dependency. To use a real device instead you would put the linux # device identifier on this line (eg: /dev/my_capture_card). # 2: The output file name. This can be pretty much anything, though best # practice is to have the extension match the appropriate value for the # source/container format (e.g. .mpg if using mpegtsmux). # 3: The flavour of the input. This flavour must be defined from options given # in org.opencastproject.mediapackage.MediaPackageElements. Known # good examples include: # presenter/source # presentation/source # audience/source # presentation/source # documents/source # indefinite/source # # To make a new input device available to the capture agent you must assign it # a unique name (without whitespace or punctuation) that will show up in the # administrative user interface. For instance, the following lines will make a # device called "audience_camera" available in the administrative interface: # # Codecs, containers, and bitrates for devices can be specified as follows: # # Codecs must be gstreamer encoders capable of accepting video/x-raw-yuv. The # codec bitrate is set relative to the encoder, because many encoders are written # by different people they do not agree on a standard format such as bps # therefore you will have to determine what prefix the encoder uses. This can be # done by executing "gst-inspect x264enc" and looking at what format the codec # expects for its bitrate (in this case, kbit/sec). # # Known good codecs include: # MPEG2: "ffenc_mpeg2video" with values in bits/sec # H264: "x264enc" *does not use bitrate, see below # Ogg Theora: "theoraenc" with values in kilobits/sec # MP2 Audio: "twolame" with values in kilobits/sec # MP3: "lame" with values in kilobits/sec # Ogg Vorbis: "vorbisenc" with values in bits/sec # # *H.264 encoding works by using a constant quantizer instead of a constant # bitrate. Therefore instead of using .bitrate use .quantizer: # The quantizer value for the x264enc element is a value from 1 - 50 (default: 21) # and it determines how much data is to be removed from each frame when encoding. # Lower quantizer values will produce more detailed videos, but with larger file sizes. # # Known good containers include: # MPEG2 Transport Steam: "mpegtsmux" # MPEG4 Layer 2: "ffmux_mp4" # Ogg: "oggmux" # Quicktime: "ffmux_mov" # # Each video source can also have a framerate associated with it. Please note # that this is not the framerate that the media is captured at, it is a software # feature that will drop, duplicate or adjust timestamps on video frames to make # it a perfect stream at the desired framerate. Also, if the framerate is not # set the device's default framerate is used. Set a desired framerate as follows: # # All pipelines have buffers which store frames before encoding. These buffers # have a limit on the number of frames (called buffers by gstreamer), the number # of bytes, and the length of time to store the information. These parameters, # when set incorrectly, can cause the output video to appear choppy. To set these # parameters the following keys have been defined with defaults for each input device: # # Keep in mind when setting these variables that increased settings can require # more powerful hardware. # name definition?? #capture.device.names=ALSA,DV_1394,VGA capture.device.names=DV_1394,VGA # Default the names of the mock devices #Create the screen capture capture.device.VGA.type=EPIPHAN_VGA2USB capture.device.VGA.flavor=presentation/source capture.device.VGA.outputfile=VGA.mpg capture.device.VGA.src=/dev/video0 #create dv_capture capture.device.DV_1394.type=DV_1394 #capture.device.DV_1394.customProducer=dv1394src ! dvdemux ! dvdec ! xvimagesink capture.device.DV_1394.outputfile=dv_1394.mpg capture.device.DV_1394.flavor=presenter/source capture.device.DV_1394.src=/dev/video0 #Create the presenter capture #Create the audio capture #capture.device.ALSA.type=ALSASRC #capture.device.ALSA.flavor=presenter/source #capture.device.ALSA.outputfile=Alsa.mp3 #capture.device.Pulse.type=PULSESRC #capture.device.Pulse.flavor=presenter/source #capture.device.Pulse.outputfile=Pulse.mp2 #capture.device.nvidia.src=hw:0 #capture.device.nvidia.outputfile=nvidia.mp2 #capture.device.nvidia.flavor=presenter/source #capture.device.nvidia.buffer.bytes=2147483648
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
