deleted: I'm not happy with my repro.
âIf this is the way Queen Victoria treats her prisoners, she doesn't deserve to have any.â
2008-03-06, 10:20 PM
As it happened...
Approx 12:30 - restarted server using mvp system panel - mvp to standby. Scheduled to record were... 15:00-15:30 TOTP2 on channel DAVE 15:30-14:00 TOTP2 on channel DAVE 18:00-18:00 TOTP2 on channel DAVE 18:30-19:00 TOTP2 on channel DAVE All recordings set for 5 minutes pre and 5 minutes post padding. At approx 18:20, I fired up the mvp/TV - guide showed recordings from 18:00 to 19:00 - I started to watch a news programme on channel STV At 18:25 the TV was kicked back to the TV Guide without any warning. I waited until the TV Guide time showed 18:27 and pressed play - news programme came back on I logged on to the server and waited until tuner1 stopped recording and went to sleeping - I then stopped the recording service so I could copy out the attached logs. Recording results were: 15:00 recorded on tuner1 - has the full 5 minutes pre and post padding 15:30 recorded on tuner1 - missing the first 5 mins, but has 5 mins post padding 18:00 recorded on tuner1 - has the full 5 minutes pre and post padding 18:30 recorded on tuner2 - 1200 bytes long
2008-03-07, 01:59 AM
Quote:Recording results were:This doesnt match what is shown in the logs. The logs show: The first recording starts at 14:55 on tuner 1 and is stopped at 15:35. (full pre+post) The second recording starts at 15:25 on tuner 2 and is stopped at 16:05. (full pre+post) The third recording starts at 17:55 on tuner 1 and is stopped 18:35. (full pre+post) So far it is exactly as I'd expect. Things start to go wrong after that. At 18:21 someone starts watching live tv starts on tuner 2. At 18:25:00.140 the app logs that it was due to start recording on tuner 2. Recordings are consider more important than live tv, and no other tuners are available, so the user is bumped out of live tv back to the menu. (ok, it'd be nice if it gave some message to the lest the user know, but thats not the case) At 18:25:00.328 it starts the fourth recording on tuner 2. At 18:25:09 it incorrectly receives a request to stop live tv on tuner 2, which causes the recording to stop. At 18:27:18 the user starts live tv again. So the problem in this case seemed to relate to some logic to do with bumping the user out of live tv when a recording is scheduled to occur on that tuner. I'll look into this and see if I can find the cause. (I dont think the others reports in this thread were cases of this - only comes into play when live tv is in use)
2008-03-07, 02:46 AM
sub Wrote:So the problem in this case seemed to relate to some logic to do with bumping the user out of live tv when a recording is scheduled to occur on that tuner. I'll look into this and see if I can find the cause. (I dont think the others reports in this thread were cases of this - only comes into play when live tv is in use)Thanks for that... I realised that Live TV had not been mentioned before, I just hoped that having two sets of back to back recordings exhibiting different behaviour might provide a clue to the problem (but as usual, I've found a totally different problem) - the DB definitely shows the 15:30 recording as having been recorded on tuner1 though... I'm beginning to suspect that I've not installed the Back-to-Back recordings patch properly (even though it seems to work the wrong way) Anyway, I'm happy to wait till after the next release to look at my specific problems again - unless you've any different ideas...
2008-03-07, 05:34 AM
Quote:the DB definitely shows the 15:30 recording as having been recorded on tuner1 though...The DB doesnt always reflect the actual tuner that was used. These intially allocations are just done to ensure everything can be squeezed in. It can still switch tuners for a few reasons. Trust me though, the recordings were on the tuners I mentioned above. Its really easy to spot which tuner was used in the logs.
2008-03-08, 11:04 PM
I think I may be seeing two seperate issues. I definitely have instances where one recording stops and a second recording is terminated at the same time.
The other issue seems similar but not neccessarily related to two simultaneous recordings. It's Saturday and the WAF wants ER (CH4) recording. Unlike previous Saturdays, there is nothing else set to record at the same time. The logs say ER started at 18:59 and finished at 20:02. I've set the signal strength to log and that also runs from 18:59 to 20:02 (quality always 100%). The logs say recording completed at 20:02. The recording however is truncated and only 12 minutes long. There are no errors in the logs. Perhaps my system just has an aversion to ER
NPVR Version= 6.1.5.231022
Intel i7 Quad Core 3200 + 16GB DDR3 Gigabyte Motherboard Windows 11 Pro 64bit TBS-6902 dual DVB-S tuner TBS-6205 quad DVB-T tuner 500Gb System Disk (M2 Nvme SSD) 4Tb Media Store (2 x 2Tb M2 Nvme SSD Raid 0) Raspberry Pi3 B+ , Pi4B (OSMC) and Pi5 (XBian) all running Kodi v21.1
2008-03-11, 12:11 AM
@Bobins
Are you using AVG ? I've found that it has been caused some recording problems for me. Unfortunately it doesn't seem to have been responsible for the original issue I posted this thread about. Still if people are getting short recordings not related to the Nova-t-500 issue it might be something to try.
2008-03-11, 12:13 AM
If you guys had used live tv any time near those recordings, the scenario I described to ACTCMS may have been the cause. There is a fix for this in 1.2.9.
2008-03-11, 10:01 PM
In my case I'm not using any anti-virus software on my GBPVR server as it's isolated from the outside world so that's not the cause.
I didn't use live TV either, it was just a plain old normal recording with no outside interference. As it occurs every week when recording ER on CH4, I'm wondering if there's something in the signal on that particular channel which causes a hang in the recording. Is there any way of working out which bit in the recording chain has hung?
NPVR Version= 6.1.5.231022
Intel i7 Quad Core 3200 + 16GB DDR3 Gigabyte Motherboard Windows 11 Pro 64bit TBS-6902 dual DVB-S tuner TBS-6205 quad DVB-T tuner 500Gb System Disk (M2 Nvme SSD) 4Tb Media Store (2 x 2Tb M2 Nvme SSD Raid 0) Raspberry Pi3 B+ , Pi4B (OSMC) and Pi5 (XBian) all running Kodi v21.1
2008-03-11, 10:02 PM
Post the logs next time it occurs and I'll take another look.
|
|