MCEBuddy 2.4.8 64bit vs 2.4.11 64bit y Tivo Remux

Errores / Solicitudes de funciones Bugs
1

MCEBuddy 2.4.8 64bit vs 2.4.11 64bit y Remux de Tivo

Acabo de hacer donaciones adicionales a MCEBuddy y Comskip.

Tengo 2 sistemas en los que ejecuto MCEBuddy: un XP con una línea dedicada a HDHomeRun y un portátil para juegos Dell G4 con Win10.

Es el segundo el que uso para descargar desde mi Tivo XL4 westerns en blanco y negro o coloreados para reproducirlos sin comerciales, después de MCEBuddy, en un WDTV Live mediante una memoria USB por la noche si no puedo dormir o me despierto.

Generalmente son archivos pequeños y se procesan rápidamente en el portátil Win10. Pueden pasar semanas antes de que vea uno. Descubrí que el sonido estaba bien en la primera mitad, pero luego se desincroniza. Hoy intenté solucionarlo con un comskip nuevo, luego pasé a la versión 2.4.11 de 64 bits y las conversiones fallaron. Como le estaba pasando a todos los programas, usé solo uno para seguir probando. Tengo Spectrum y me pregunté si, dado que venden un canal de westerns sin comerciales, podrían haber hecho cambios en el canal que grabo. Cuando pasé a la 2.4.11, los programas fallaban rápidamente en el remux de Tivo.

Así que intenté procesar el programa en la máquina XP, que ejecuta la 2.3.15, y obtuve un archivo convertido que también empezó con el sonido desincronizado a mitad de camino.

En el portátil Win10 para juegos renombré mi directorio de comskip como comskip.old, pero por supuesto, cuando falla el remux de Tivo, no llega a comskip.

En el portátil Win10 acabo de introducir mi clave de Tivo Desktop Plus, pero aún así falla en el remux de Tivo.

Estoy usando los archivos de comskip de pago, sin modificaciones.

BillJ

En la máquina Win10 volví a una versión anterior, 2.4 Beta 1, y de nuevo puedo superar el Remux de Tivo y convertir el archivo a mp4, pero nuevamente hay un problema de sincronización de sonido y probablemente ocurre después de un corte de comercial. Pensé que podría deberse a tener directorios temporales en la unidad D: en lugar del elemento de estado sólido, pero moverlo a C: no ayudó. Ahora estoy probando con otro archivo de tivo.

2

¿Puedes adjuntar el archivo de registro de ambas conversiones, la antigua 2.3.15 y la nueva 2.4.11? No debería haber ninguna diferencia en la parte de remuxing de tivo si la configuración es la misma. ¿Estás usando TiVO desktop (rápido) o transferencias lentas (KMTTG)? No está relacionado con comskip sino con volver a unir el archivo, donde la versión anterior a veces se desincronizaba, lo cual fue corregido en las versiones más recientes.

3

Llevo horas con esto y he hecho cambios, así que los archivos de registro pueden resultar confusos.

Tras volver a una versión anterior de MCEBuddy en la máquina Win10, pude volver a realizar conversiones. No hay prácticamente diferencia entre esta y la conversión en la máquina XP con 2.3.15. Ambas presentan problemas de sincronización de audio.

En la máquina Win10 he estado probando diferentes conversiones sin eliminar comerciales. Intenté AVI sin procesar y la sincronización era buena al inicio de un western (me decanto por los anteriores a 1955), pero al saltar al final se perdía la sincronización.

Acabo de probar AVI Mpeg2 sin corte de comerciales, con la misma película de Roy Rogers. Al revisarla, el audio está sincronizado hasta el primer anuncio; después del anuncio se desfasa.

Así que algo relacionado con los comerciales, aunque se ignoren, estropea la sincronización.

Curiosamente, cuando empecé a grabar westerns, programé la grabación de todos los episodios de Zane Grey Theatre, pero Charter/Spectrum anunciaba 4 ó 5 episodios de varias temporadas seguidas y emitía anuncios llamativos en su lugar, bloqueando efectivamente la grabación de esos episodios si se volvían a emitir.

Así que, de nuevo, creo que es algo hecho deliberadamente para impedir la eliminación de comerciales.

BillJ

4

Así que, un archivo de Tivo de un western pierde la sincronización después del primer comercial, tanto en la XP con 2.3.15 como en la Dell G3 con 2.4 beta, mientras que la Dell G3 con 2.4.11 falla en el remux.

Esta mañana grabé un episodio de Death Valley Days con el HDHR en una línea dedicada a la máquina XP y luego ejecuté MCEBuddy 2.3.15. Obtuve un video perfecto, sin comerciales y sin pérdida de sincronización de audio.

Noto que si intento copiar el archivo .ts del HDHR a una memoria USB para probar su conversión en la Dell con Win10, aparece un mensaje que dice: «/Confirmar pérdida de secuencia. El archivo … tiene información adicional adjunta que podría perderse si continúa copiando. El contenido del archivo no se verá afectado. La información que podría perderse incluye: :metadata.xml:$DATA y :Timing.Info:$$DATA».

También grabé el programa en Tivo. Lo transferiré a la máquina XP e intentaré moverlo a la memoria USB. Si no se menciona pérdida de datos al copiar, entonces quizás el problema es que Tivo no transfiere Timing.Info:$$DATA.

BillJ

5

El archivo .ts de video grabado por Silicondust HDHR3 de Death Valley Days, copiado a la memoria USB y luego a la máquina Win10, fue procesado por MCEBuddy 2.4 beta a MP4 Normal. No tenía marcado el eliminador de comerciales, ya que esa fue la última prueba de anoche. El archivo MP4 resultante se reproduce perfectamente hasta el final. Por lo tanto, el Timing.Info:$$DATA que se retrasó al copiar el archivo .ts desde la máquina XP no es crítico para la conversión exitosa. Habría algún otro problema con los archivos .tivo.

6

Copiar el archivo .tivo desde la máquina XP al dispositivo USB no menciona ningún $$DATA retenido.

Iniciar la conversión en la máquina XP al mismo tiempo que en la máquina Win10… la máquina XP es más lenta y tomará unos 3½ minutos (el video en blanco y negro es un archivo muy pequeño en comparación)… Win10 terminó primero usando la versión 2.4 beta, la sincronización falla hacia el final. Al verificar la conversión finalizada en XP 2.3.15, la sincronización también falla en la segunda mitad del archivo convertido en la máquina XP.

Entonces, el archivo grabado por SiliconDust HomeRun 3 se convierte con éxito, pero los archivos grabados por Tivo transferidos a cualquiera de las máquinas no mantienen la sincronización de sonido durante todo el video.

Noto que la transferencia rápida de Tivo Desktop está desmarcada.

7

Probando MCEBuddy 2.5 Beta 1 en la máquina Win10 con archivo .tivo. MP4 Normal falló en remux. AVI MPeg2 falló en remux. Cambié la configuración a no remux. Reinicié la máquina, verifiqué que no remux estuviera marcado, inicié la conversión y esta beta ignoró el no remux con el resultado de que la conversión murió. Intenté AVI Mpeg2 sin procesar y nuevamente con no remux marcado, el programa intentó remux y la conversión murió.

Debo mencionar que no solo uso la transferencia lenta de Tivo Desktop sino que uso exclusivamente MCEBuddy.ServiceCMD.exe y tengo deshabilitado el Servicio de Windows de MCEBuddy. Probaré una transferencia rápida de Tivo.

Máquina Win10, portátil Dell G3, transferencia de Tivo Desktop del episodio de Death Valley Days usando transferencia rápida de Tivo (desde un XL4), MCEBuddy 2.5 Beta 1 (18 de julio de 2019), Servicio de Línea de Comandos MCEBuddy 2.x, Convertir a MP4 con no remux marcado, la conversión falló tras un intento de remux. ¿Quizás los dispositivos Tivo modernos envían un archivo diferente?

8

Conseguir una grabación limpia en la máquina XP con la línea al SiliconDust costó un poco, aunque el problema podría haber estado en el procesamiento de datos de MCEBuddy. Inicialmente tenía el SiliconDust en la red, pero las cosas mejoraron cuando añadí una segunda NIC exclusivamente para el SiliconDust. Aun así, seguía teniendo fallos en los archivos finales. La configuración final que mejor funcionaba era desactivar la NIC conectada a internet antes de empezar a grabar por la noche. Luego, al final de la noche, volvía a activar la NIC conectada a internet y arrancaba MCEBuddy. Pero había algo más: antes de empezar a grabar, ejecutaba mi kill.tivo.bat, que cerraba los dos archivos de tivo, tivotransfer.exe y tivonotify.exe, así como navegadores y programas de correo que pudieran estar abiertos. Con seguridad, o tivotransfer.exe o tivonotify.exe hacían algo periódicamente que interrumpía la grabación o el posterior procesamiento de datos de MCEBuddy. El efecto de los archivos de tivo era hacer que el SiliconDust fuera menos eficaz o impedir que MCEBuddy distinguiera claramente qué era programa y qué eran anuncios.

9

Probé algo diferente en el portátil para juegos Dell G3 con Win10. Después de desinstalar el MCEBuddy 2.5 Beta 1 de 64 bits, instalé la última versión estable de 32 bits, la 2.4.11. Probé con una película grabada recientemente transferida desde Tivo. Ahora mismo ha avanzado bastante en «Remuxing TiVO file…». Nunca antes había llegado tan lejos. Cuando probé esta película con la versión de 64 bits obtuve en el registro un «System.BadImageFormatException», así que lo busqué. En codeproject.com dice: «Por lo general, está relacionado con la diferencia entre compilaciones y procesos de DLL de 64 y 32 bits».

Falló después del remux. En el registro: «Unsupported codec with id 0 for input stream 2». Stream #0:0 Video mpeg2video; Stream #0:1 Audio ac3; Stream #0:2 Unknown:none. Esto fue con la transferencia rápida de Tivo Desktop. Probaré con transferencia lenta…

Remux… análisis de anuncios… funcionando… falla. Nota: «Ignore copy protection» nunca ha estado marcado.

Encontré dónde cometí un error. Al pasar a la versión de 32 bits, ésta se instala en «Program Files (x86)\MCEBuddy2x» y, aunque cambié la ubicación del comskip.ini, no cambié la del comskip.exe. Volveré a ejecutar algunas pruebas.

Pasé a programas en lugar de películas y probé de nuevo una grabación de Tivo de «Death Valley Days». Casi funcionó: llegó al minuto 14 de un episodio de 22 minutos antes de perder sincronía, pero no dejé el ordenador completamente sin intervención durante el proceso. Probaré otra vez con una película.

10

Te envié un mensaje privado y lo investigaré.

11

32 bits estable, transferencia lenta, película Revolver.tivo, remuxing, analizando, comskip funcionando, cortando… fusionando… analizando… convirtiendo… (12 minutos 44 segundos esperados)… finalizado. Verificando. Sincronización buena a los 57 minutos 1:41 más o menos, ligeramente desfasada a 1:19, y todavía ligeramente desfasada al final. Quizá sea un problema de tamaño de memoria y que la unidad es híbrida y no un SSD completo.

Cambiado a shows/other y shows. Comenzó un Zane Grey b&w .tivo. Sincronización un poco desfasada hacia el final.

Probando 3 videos de Death Valley Days desde SilconDust HDHR3. Noto que cuando grabo con HDHR3, si hay más de un episodio ese día o noche, todos aparecen con la serie, episodio y nombre de la primera grabación de ese programa esa noche. A veces ni siquiera hace eso, solo da la fecha y hora de la grabación. Todos grabados/convertidos perfectamente.

Ahora volviendo a Beta 1 64 bits y re-descargando rápidamente en un intento de reproducir el fallo que apareció hoy.

Ejecutando 2.5 beta 1, Revolver.tivo, transferencia rápida, falló. He duplicado el System.BadImageFormatException y enviando el registro a Goose.

12

La BadImageFormatException con la compilación de 64 bits de MCEBuddy para remuxing de TiVO ha sido corregida en la compilación BETA 2.5.1 de hoy. Era un problema introducido en la compilación de 64 bits 2.4.9 durante un cambio de optimización.

13

Gracias, Goose.

14

Muy bien. Gracias.