[Jde-dev] bug en recordingserver
Sara Marugan
smarugan en gsyc.es
Mar Abr 27 11:13:13 CEST 2010
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?
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...
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
>>
>
>
More information about the Jde-developers
mailing list