Consegui retirar a limitação de 6 horas contínuas para a gravação. Para o agendamento, o limite ficou em 23 horas e 59 minutos devido à forma de como o mesmo é feito: na tela de agendamento não é possível escolher a data do fim das gravações mas apenas a data e hora do início, a hora final, o canal a ser gravado e o modo (diário, semanal, uma vez etc).
Esse forma mais simples é bem interessante. A data final é calculada automaticamente, sendo no mesmo dia, caso a diferença entre as horas final e inicial forem positivas ou em d+1 caso a diferença seja negativa. Assim, por exemplo, se programarmos o início de uma gravação no dia d, hora 13:00 e o término para as 12:59, a data final será em d+1, totalizando 23 horas e 59 minutos. Se a hora final for igual (13:00, no caso do exemplo) ele não aceita, pois considera que há sobreposição de gravação. Esse cálculo já era feito anteriormente, mas limitado a 6 horas. Mais que isso havia o aviso de "hora incorreta informada".
Já para o OTR a ideia foi deixar o limite em 24 horas, para ficar compatível com o limite do agendamento e evitar um arquivo gigante. Como teste, cheguei a fazer duas gravações, uma de aproximadamente de 8 horas e meia e outra de um pouco mais de 10 horas. A primeira foi com OTR e a segunda com agendamento.
Bug
Há um bug no firmware original o qual não consegui retirar e que atrapalha agendamentos superiores a 6 horas. Como explicado, quando se tentava agendar uma gravação com horário de término inferior ao horário inicial, a data de término passava a ser o dia seguinte, desde que não fosse superior a 6 horas. Exemplo: inicio às 22:00 e término às 4:00 era aceito (6 horas de gravação). Já início às 22:00 e término às 21:00 não era aceito, pois totalizaria 23 horas de gravação. Porém, ao se tentar agendar um início na faixa da 0 hora (0:00 a 0:59) e um final em horário anterior, mas na mesma faixa da 0 hora, o aparelho, além de aceitar o agendamento, não atualizava a data em d+1. Exemplo: início 20 de abril à 0:15 e término à 0:10 ele aceitava e colocava a data de término como no próprio dia 20 de abril. Nunca tentei gravar assim e não sei o que acontece. Agora, sem o limite de 6 horas, esse tipo de agendamento continua passando. Por enquanto, a sugestão para quem for fazer uma gravação longa de madrugada é não começar na faixa da 0 hora ou, se começar, terminar no máximo na faixa das 23 horas, a não ser que a diferença seja positiva.
Um pequeno resumo sobre a gravação
Como se sabe, o horário de agendamento segue a informação das emissoras, já que o aparelho não possui timer. A gravação é feita em arquivo único quando o disco está em ext3 ou dividida em arquivos de 3,9GB quando o disco está em FAT32, nomeados com a data e a hora inicial da gravação. Neste último caso, a reprodução do aparelho agrupa os arquivos de forma transparente ao usuário, como se fossem apenas uma gravação.
Durante a reprodução, a navegação pode ser agilizada com o uso das teclas numéricas: o tempo de gravação é dividido em 10 partes iguais e podemos saltar diretamente para cada parte pressionando as teclas de 0 a 9 no controle. Isso funciona bem quando o arquivo é único (ext3). Mas quando estamos em FAT32, gera um certo inconveniente. Cada arquivo de 3,9GB é dividido em 10 partes. Então você só pode saltar entre as partes do arquivo atual.
Nos testes que eu fiz, gravando a Globo HD, no limite de 6 horas foram gerados 10 arquivos, totalizando 39GB. Cada arquivo ficou com 36 minutos, divididos em 10 partes de aproximadamente 3 minutos e 40 segundos (3,6 minutos). Assim, se quisesse saltar para o final da gravação mais rapidamente, teria que apertar a tecla 9 para ir ao final do primeiro bloco (arquivo), selecionar avanço rápido (32x) e esperar ele passar ao próximo bloco. Ao chegar ao próximo bloco, selecionar avanço normal e apertar 9 novamente para ir ao final do segundo bloco e repetir a operação. Enfim, intercalando saltos de 32,4 minutos com correrias de 3,6 minutos. Quando a gravação for muito grande (por exemplo, 24 horas), isso será muito trabalhoso. Mas acho que o único motivo para se fazer uma gravação tão grande em FAT32 será para se tentar alguma edição posterior no PC. Ainda assim, uma forma de facilitar a exibição de uma gravação grande em FAT32 seria alterar os arquivos textos gerados que agrupam a gravação. Pode-se facilmente dividir uma gravação de 12 horas, com 20 arquivos, em 4 gravações de 3 horas, com 5 arquivos cada. Isso não é difícil, mas é necessário olhar os arquivos para se familiarizar e deduzir como é feito. Existe um arquivo .link com a listagem dos blocos, de mesmo nome do primeiro bloco e um arquivo .info contendo apenas o nome do primeiro bloco e também de mesmo nome deste. No exemplo citado, bastaria criar 4 arquivos .link (com 5 blocos cada) e 4 arquivos .info apontando para o bloco que inicia cada uma das novas "seções" criadas manualmente.
Por outro lado, no formato ext3 próprio do aparelho, também podemos ter problemas com gravações muito grandes. Apesar de facilitar a reprodução, já que temos apenas um arquivo para navegar, quanto maior o arquivo, maior o tamanho dos saltos. Em uma gravação de 24 horas teremos 10 partes de 1 hora e 40 minutos cada.
Modificações
Procurei por referências a string que o zeurt havia indicado ("pvr: stream has recode 6hrs") em uma rotina que fazia referências a outras strings relacionadas ao PVR. A rotina é a sub_4BD51C e encontrei as referências nos seguintes pontos, já que o valor de $s5 era 0x690000:
.text:004BD814 58 B0 A4 26 addiu $a0, $s5, -0x4FA8 # string pvr maximo 6 horas
.text:004BD994 58 B0 A4 26 addiu $a0, $s5, -0x4FA8 # string pvr maximo 6 horas
Verificando a rotina, há dois pontos em que o cálculo é feito:
.text:004BD7B8 49 01 02 3C lui $v0, 0x149 # calculo das 6 horas #1490000 or #9700 = #1499700
.text:004BD7BC 00 97 54 34 ori $s4, $v0, 0x9700
.text:004BD94C 49 01 02 3C lui $v0, 0x149 # calculo das 6 horas #1490000 or #9700 = #1499700
.text:004BD950 00 97 54 34 ori $s4, $v0, 0x9700
Deduzi que esses seriam os pontos pois 0x1499700 dividido por 3600 (3600 segundos), depois por 10 e transformado em decimal dá 600 (isso parece BCD para 6 horas, 0 minutos e 0 segundos).
Além desses pontos, existem ainda mais um em outra rotina:
.text:004BA72C 49 01 02 3C lui $v0, 0x149 # calculo das 6 horas #1490000 or #9700 = #1499700
.text:004BA730 00 97 54 34 ori $s4, $v0, 0x9700
E uma palavra em:
.rodata:0068B490 00 97 49 01 dword_68B490: .word 0x1499700 # DATA XREF: sub_4BEA88+428_o
.rodata:0068B490 # sub_4BEA88+430_r ...
.rodata:0068B490 # limite 6 horas
Essa palavra é referenciada por uma rotina que também está relacionada ao PVR.
Alterar esses valores não permitiu agendamentos superiores a 6 horas. Isso porque essas rotinas apenas verificam se o a gravação atingiu o tempo máximo (e a interrompem). A rotina responsável pelo agendamento e os critérios de aceitação é a sub_4D4C48. Um trecho chamou a atenção:
addiu $v0, $v1, (byte_68D380 - 0x690000) # 6 horas no agendamento pvr
lbu $a0, (byte_68D380 - 0x690000)($v1) # carrega byte 6. 6 horas
lbu $a2, 2($v0)
lbu $a1, 1($v0)
Esse trecho carrega em $a0, $a1 e $a2 os valores 0x6, 0 e 0 (bytes que estão a partir de 0x68D380), respectivamente. Isso é BCD, pois somente foi aceito o agendamento de até 23 horas e 59 minutos após eu mudar para 0x24, 0 e 0, respectivamente (ao colocar 0x18, que é 24 em hexadecimal, o limite de horas passou a ser 18 e não 24, o que evidenciou se tratar de BCD). Isso foi mais um indício de que o valor achado anteriormente, 0x1499700, também estava relacionado ao limite.
Ao apenas mudar esse ponto, o agendamento superior a 6 horas passou a ser permitido, mas a gravação ainda era interrompida após completar 6 horas. Então, mudando as 4 ocorrências do valor 0x1499700 apontadas anteriormente para o seu quádruplo (0x5265C00) finalmente foi permitido gravar mais que 6 horas.
A dúvida ainda é saber se a mudança daquele valor para o quádruplo realmente limita a gravação em 24 horas. Pode ser que deixe passar, se o cálculo não for tão simples. No caso do agendamento, isso não tem problema, pois a agenda será seguida (eu testei até 10 horas e pouco) e a gravação será limitada a 23 horas e 59 minutos. Já no caso do OTR eu não tive paciência para testar (interrompi com 8 horas e meia). Então, quando disponibilizar o firmware, fica a sugestão para testes.
Eu imagino que o bug da 0 hora esteja na rotina sub_460178, chamada pela que faz o agendamento. Ela é quem recebe os valores e parece fazer os cálculos das diferenças entre os horários. Ainda não tentei entendê-la, mas qualquer mudança nela deverá ser feita com cuidado, já que é chamada por diversas outras rotinas.
