OK, it happened again. I am getting single byte recordings on an Australian channel called GEM. Yesterday morning I retuned all channels and did a quick check - I was getting a recording on GEM.
This morning I set a manual recording on all channels and GEM has again failed with a zero byte file. I checked Live TV and I get a good picture. Just in case there was a problem with the PostProcessing script I disabled it but I still have a zero byte recording on this channel.
Any ideas?
Create a c:\temp directory, and set HKEY_LOCAL_MACHINE\Software\NPVR\LogTSWriter=1 in the registry, then reboot and try recording the channel in question, then zip and post the c:\temp\writer-xxx.log and your npvr.log/nrecord.log files.
OK, c:\temp already exists. Deleted all exiting content. Added registry item (assumed that it was a text string like the others) and restarted. Created a 10 minute manual recording on GEM, zero byte as usual. Did not disable PostProcessing.bat that transcodes to mpg (sorry). Log directory and temp directory zips attached. Note that temp directory has a crash dump??
thanks sub.
Greg
What was the named of the failed recording? You seem to have three recordings in those logs.
Was it F:\GEMTEST2\GEMTEST2_20110226_18501900.ts? It looks like its writing quite a bit of data to that file, so it shouldnt be zero bytes. (unless you're out of disk space and all those writes are failing)
OK, the culprit seems to be the PostProcessing.bat script. Plenty of space on both the C:\ drive (80GB) and the recording drive (380GB). I disabled the PostProcessing script and the TS file is non-zero. I have set up a test for all three channels on the same frequency (NBN, GO! & GEM) with PostProcessing once again enabled.
The PostProcessing script I am using is (which I got from asking an earlier question in the forum):
cd C:\Program Files\NPVR\Other\
ffmpeg -i %1 -map_meta_data 0:0,p1 -f vob -ab 128000 -acodec mp2 -b 2500k -vcodec mpeg2video -deinterlace "%~dpn1.mpg"
del %1
EOF
Results of the test: Three simultaneous recordings of the 3 channels on the one frequency. With no PostProcessing I get TS files with non-zero sizes. Running the above PostProcessing script, only GEM gives a zero-byte file, the others are OK.
Any ideas???
I dont know. I'd stick with the original .ts files.
The .ts files are very large. It's not a matter of disk space but that the videos are viewed via the NEWA web server over wireless. Once transcoded, the .mpg file is about 1/3 the size of the .ts and are therefore more amenable to wifi.
Not only that but playback of the .ts file is problematic. Using VLC there is no time information, so it's hard to jump to the part of the file that is wanted.
I'll keep playing around with ffmpeg. Thanks for your help.
Quote:The .ts files are very large. It's not a matter of disk space but that the videos are viewed via the NEWA web server over wireless. Once transcoded, the .mpg file is about 1/3 the size of the .ts and are therefore more amenable to wifi.
I'm pretty sure NEWA doesnt stream the original file anyway, and always transcodes it to a different format, so it shouldnt make any difference to the amount of bits sent over wifi.
When I play a recording over NEWA, the filename that appears at the top of the VLC window ends in TS. I can't find anything about transcoding in NEWA?? There also seems to be a bug in the new NEWA that throws an exception when it tries to serve large files?? I have a post in that forum.
I tried a different incantation of ffmpeg, courtesy of a post from pBS. I now get video in GEM but no audio. MPG files definitely give me a better experience, so I'll pursue this line of experimentation. Now to delve into the ffmpeg documentation...
ffmpeg -ss 2 -y -i %1 -async 200 -qscale 4 -s 720x480 -vcodec mpeg2video -ac 2 -acodec mp2 -ar 48000 -ab 160k "%~dpn1.mpg"