Bug display on recording pages

[domserge]

Version: 5.1.1.210329

Bug on webapp

I have 2 reccuring recording
JS at 13:30
C8 test at 06:00
   

When i click on C8 sport the display is correct:
The displayed date/time is correct
After i click on the second (JS) ans the display is wrong (Time is not correct)
we have 06:00 and not the correct time 13:30
       

the first date/time is used for each .
Same things on pending view.
Regards

[Graham]

Version: 5.1.1.210329
Bug on webapp
I have 2 reccuring recording
JS at 13:30
C8 test at 06:00
When i click on JS the display is correct:
The displayed date/time is correct
After i click on the second (C8 test) ans the display is wrong (Time is not correct)

Please can you edit your post to remove the blank lines ... Thank you.

Please attach a screenshot showing the problem that you see. Thanks.

Please attach logs ... https://github.com/sub3/NextPVR/wiki/get-help ... Thanks.

[domserge]

Version: 5.1.1.210329
Bug on webapp
I have 2 reccuring recording
JS at 13:30
C8 test at 06:00
When i click on JS the display is correct:
The displayed date/time is correct
After i click on the second (C8 test) ans the display is wrong (Time is not correct)

Please can you edit your post to remove the blank lines ... Thank you.

Please attach a screenshot showing the problem that you see.  Thanks.

Please attach logs ... https://github.com/sub3/NextPVR/wiki/get-help ... Thanks.

Sorry , the post is updated
Thanks

[Graham]

Version: 5.1.1.210329

Bug on webapp

I have 2 reccuring recording
JS at 13:30
C8 test at 06:00


When i click on C8 sport the display is correct:
The displayed date/time is correct
After i click on the second (JS) ans the display is wrong (Time is not correct)
we have 06:00 and not the correct time 13:30


the first date/time is used for each .
Same things on pending view.
Regards

Sorry ... the nrecord.log is full of this error ...

2021-04-01 18:00:25.041 [DEBUG][32] Sending m3u8
2021-04-01 18:00:25.042 [DEBUG][20] Sending m3u8
2021-04-01 18:00:25.042 [DEBUG][179] Sending m3u8
2021-04-01 18:00:25.061 [DEBUG][157] This shouldn't happen...
2021-04-01 18:00:25.061 [DEBUG][157] end
2021-04-01 18:00:25.061 [DEBUG][157] Sending m3u8
2021-04-01 18:00:25.122 [ERROR][94] Unexpected error in WriteSafeReadAllLines: System.IO.FileNotFoundException: Could not find file 'C:\Users\Public\NPVR-data\web\temp\JS-ae17f404fe2b42cba2943d49a38f67fe.m3u8'.

I can't see the recurring recording problem because of the errors in the logs.

I know very little about IPTV and can't help with the missing file problem ... I expect that someone that can help will be along soon.

[mvallevand]

Graham, I have seen this before too. When you add or update a manual recording the time/date don't always reflect the database time or default time. I believe it is a browse cache issue. You can see it easily, if you add a manual recording and then add another manual recording without doing a refresh the second entry gets the time from the first entry rather. If you ctrl-f5 between you get sub's default.

Martin

[sub]

I think this is a web app issue I noticed a couple of days ago. The first time the popup window is displayed (when you click on a recording), the control is initialized as a datetimepicker, and gets the right date/time. If you stay on the page, and click another recordings, and it goes to show the popup, it's already a datetimepicker and seems to ignore the attempt to set the date/time, so you still see the date/time from the previous viewing of the popup.

It's on my list to fix.

[sub]

I think this is a web app issue I noticed a couple of days ago. The first time the popup window is displayed (when you click on a recording), the control is initialized as a datetimepicker, and gets the right date/time. If you stay on the page, and click another recordings, and it goes to show the popup, it's already a datetimepicker and seems to ignore the attempt to set the date/time, so you still see the date/time from the previous viewing of the popup.

It's on my list to fix.

I've fixed this for the next build.

This was only an issue for manual recordings (where you explictly specify times etc), so not that frequently used by most people. I don't think anyone has noticied it before.