[Jde-dev] bug en recordingserver
Roberto Calvo
rocapal en libresoft.es
Mar Abr 27 17:21:35 CEST 2010
El mar, 27-04-2010 a las 11:13 +0200, Sara Marugan escribió:
> Ok, me he bajado el repositorio y voy a probar que tal.
>
> Acabo de ver que en recordingserver.c hay una llamada a una función con
> un id de BBDD constante (linea 50):
>
> virtual jderobot::RecordingSequence getRecordings(const
> Ice::Current& c){
>
> RecordingLog* recLog = initRecordingHandler();
>
> getThumbRecording(72,c);
>
> return recLog->getAllRecording();
>
> }
>
> Qué explicación tiene esto?
Que me faltan horas de sueño!! jejeje Gracias por comentarlo Sara, es
que esa llamada era para hacer pruebas con una grabación en concreta. Ya
lo he quitado y en el proximo commit lo subiré, o subelo tú, me es
igual.
>
>
> Otra cosa, ya tengo casi listo el objeto mencoderRecorder que graba
> vÃdeo a partir de las imágenes de una cámara de jderobot. El único
> problema que me encuentro es que necesito lanzar dos procesos (uno que
> recibe las imágenes y las mete en un fifo y otro que ejecuta mencoder
> que lee de ese fifo) y el stopRecording sólo mata el proceso del
> mencoder. El otro termina pero se queda defunct y no consigo que no pase
> esto ni con pthread_exit, pthread_kill, pthread_cancel...
Si vemos, que podemos tener numerosas maneras de matar los procesos,
podemos hacer que el método stopRecording sea virtual y le implemente
cada uno.
De todas formas, si lo haces con fork() puedes detectar cuando muere un
proceso y entonces te cargas al otro también. Mira el código de
ffmpegRecorder, justo después del wait().
>
> por lo demás estarÃa listo.
>
> Un saludo
>
> Roberto Calvo wrote:
> > Sara, he subido unas modificaciones al svn para solucionar este
> > problema, al final han sido pocas. Ahora el startRecording devuelve el
> > ID único, y no el pid_id.
> >
> > El recordingManager, suelta estas trazas:
> >
> > [*] Recording with ID: 122(5677) starting correctly!
> > [*] Recording ID: 122 is being stopping!
> >
> >
> > 122 es el id único de BBBDD y 5677 es el PID (que sólo conoce él). si
> > quieres echa un ojo al componente surveillance que es de la misma manera
> > que interactuarás en tu código.
> >
> > Ahora deberÃas poder asociar eventos a grabaciones con ese ID sin
> > problemas.
> >
> > un saludo!
> >
> > El lun, 26-04-2010 a las 11:55 +0200, Sara Marugan escribió:
> >
> >> Esa opción también la pensé pero la descarté porque vi que las
> >> aplicaciones debÃan guardar el pid para llamar al stop del
> >> recordingmanager. Sin embargo si se hace la conversión en el
> >> recordingmanager todo queda más encapsulado. Además lo de posibles ids
> >> duplicados no se puede permitir claro.
> >>
> >> Me parece bien esta solución!
> >>
> >>
> >> Roberto Calvo wrote:
> >>
> >>> mmm no podemos usar el PID como ID, porque pueden existir varios
> >>> RECORDER en diferentes máquinas y podrÃa pasar que hubiera 2 grabaciones
> >>> con el mismo PID.
> >>>
> >>> Después de leer tus correos y comentar una posible solución con Jose
> >>> MarÃa, hemos llegado a esta conclusión, a ver que te parece. En el
> >>> RecorderConfig sólo guardamos un campo id, y depende de quienes hablen,
> >>> tiene una semántico u otra.
> >>>
> >>> -> Entre el Recorder y RecordingManager, id = PID. Únicamente se usa
> >>> para empezar y parar la grabación.
> >>>
> >>> -> Entre el RecordingManager y los demás componentes, id = id_BBDD.
> >>>
> >>> -> El RecordingManager es el encargado de hacer la transformación de
> >>> id_BBDD a PID para poder parar las grabaciones (esos datos están en la
> >>> BBDD).
> >>>
> >>>
> >>> ¿Qué te parece? Estoy cambiando algo de código para ver si no se nos ha
> >>> pasado nada en esta solución, pero parece la que más desacopla y
> >>> encapsula el tema del PID, que es exclusivamente lógica del Recorder.
> >>>
> >>> un saludo!
> >>>
> >>> El lun, 26-04-2010 a las 10:50 +0200, Sara Marugan escribió:
> >>>
> >>>
> >>>> Finalmente creo que la mejor opción es dejar sólo un id en RecordConfig,
> >>>> que se corresponda con el pid. El id de la BBDD sólo se necesita al
> >>>> insertar un nuevo evento sobre la grabación.
> >>>>
> >>>> Ahora mismo como lo tengo es que antes de hacer la insercción del
> >>>> evento, consulta el id de la BBDD de la grabación sobre la que quiere
> >>>> guardar el evento. Lo único que no me acaba de gustar es que tras la
> >>>> consulta hay que volver a conectar con la BBDD para que funcione la
> >>>> insercción.
> >>>>
> >>>> Qué os parece esta solución?lo demás se deja tal y como estaba.
> >>>>
> >>>>
> >>>>
> >>>> Sara Marugan wrote:
> >>>>
> >>>>
> >>>>> Pensándolo he llegado a la conclusión de que se necesitan almacenar
> >>>>> ambos ids. El id de la base de datos lo necesitan tanto la aplicación
> >>>>> que guarda eventos como la que los quiere consultar después. Y el id que
> >>>>> viene del pid lo necesita recorder para matar el proceso de grabación.
> >>>>>
> >>>>> Ahora mismo como está (sin el cambio) las aplicaciones sólo pueden
> >>>>> acceder al id del pid, que es lo que se almacena.
> >>>>>
> >>>>> Asà que todo apunta a que hay que introducir el campo recoding_id en la
> >>>>> configuracion de una grabación.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Roberto Calvo wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Sobre los eventos aún no he trabajado con la ultima versión. Pero te
> >>>>>> comento unas cosas sobre los ids:
> >>>>>>
> >>>>>> * El id_rec es el pid del proceso que realiza la grabación, sólo tiene
> >>>>>> sentido usarlo cuando la grabación está en curso (para detener el
> >>>>>> proceso).
> >>>>>> * El id es el identificador único de grabación, que se utiliza para
> >>>>>> todo lo demás en grabaciones.
> >>>>>>
> >>>>>> El código que me pegas, es justo el primer caso, se está lanzando la
> >>>>>> grabación, recoge el pid de proceso. En ese mismo momento el recorder no
> >>>>>> sabe nada de ID's de base de datos, eso lo sabe el recordingManager.
> >>>>>>
> >>>>>> Según lo que comentas, necesitamos tener en el RecorderConfig dos
> >>>>>> atributos, uno que sea el id normal, y otro el id_rec ¿Con eso se
> >>>>>> solucionarÃa el problema, verdad?
> >>>>>>
> >>>>>> Además, fÃjate que cuando haces un getRecordings, el id si introduce el
> >>>>>> correcto, el id único de la BBDD. Si te parece cuéntame un poco más el
> >>>>>> problema que tienes y el contexto y vemos como solucionarlo, aunque lo
> >>>>>> que he puesto en el párrafo anterior tiene sentido que lo hagamos.
> >>>>>>
> >>>>>> Mirando el código, creo que el problema pueda estar en que utilizas el
> >>>>>> id que devuelve el RecorderConfig al empezar una grabación, para
> >>>>>> establecer los eventos de esa grabación ¿es asÃ? Si es asÃ, creo que la
> >>>>>> solución pasa por tener un solo campo id en el RecorderConfig, y que sea
> >>>>>> el propio recordingManager quien se capaz de obtener el PID, que desde
> >>>>>> luego tiene mucho más sentido.
> >>>>>>
> >>>>>> ConfÃrmame esto último que te comento, y lo cambiamos.
> >>>>>>
> >>>>>> Gracias por el reporte!
> >>>>>> un saludo!
> >>>>>>
> >>>>>> El jue, 22-04-2010 a las 13:21 +0200, Sara Marugan escribió:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Hola,
> >>>>>>>
> >>>>>>> haciendo pruebas con recordingserver me daba error al intentar guardar
> >>>>>>> un evento sobre una grabación previamente guardada. Concretamente es que
> >>>>>>> no coincidÃa el campo recording_id del evento con el id de la grabación.
> >>>>>>> Las grabaciones tienen un id y un recording_id. La foreing key de los
> >>>>>>> eventos necesita apuntar al id de una grabación, no al recording_id, que
> >>>>>>> es como está ahora.
> >>>>>>>
> >>>>>>> Pongo aquà el snip de código de recordingserver.cpp (lÃnea 78):
> >>>>>>>
> >>>>>>> // Read the PID
> >>>>>>> read (descPipe[0], &pid_rec, sizeof(int));
> >>>>>>> //printf("#### rid from insert %d\n",rid);
> >>>>>>> recConfig->id = pid_rec;
> >>>>>>>
> >>>>>>> // Log recording
> >>>>>>> int rid=recLog->startRecording(recConfig);
> >>>>>>>
> >>>>>>> //return pid_rec;
> >>>>>>> return rid;
> >>>>>>>
> >>>>>>> Cambiando esto funciona bien. Creo el ticket y subo el parche?
> >>>>>>>
> >>>>>>> Un saludo.
> >>>>>>>
> >>>>>>> Sara.
> >>>>>>> _______________________________________________
> >>>>>>> Jde-developers mailing list
> >>>>>>> Jde-developers en gsyc.es
> >>>>>>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Jde-developers mailing list
> >>>>> Jde-developers en gsyc.es
> >>>>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Jde-developers mailing list
> >>>> Jde-developers en gsyc.es
> >>>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >>>>
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> Jde-developers mailing list
> >> Jde-developers en gsyc.es
> >> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >>
> >
> >
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
--
Roberto Calvo Palomino | Libre Software Engineering Lab (GSyC)
Tel: (+34) 91 488 85 23 | Universidad Rey Juan Carlos
rocapal en libresoft.es | Edif. Departamental II - Despacho 116
http://libresoft.es/ | c/Tulipán s/n 28933 Móstoles (Madrid)
GPG-KEY: http://gsyc.es/~rocapal/rocapal.gpg
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre : no disponible
Tipo : application/pgp-signature
Tamaño : 198 bytes
Descripción: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
digitalmente
Url : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100427/51d1474e/attachment.pgp
More information about the Jde-developers
mailing list