client/server show different times

[pBS]

possible bug, the client and main machine show different show lengths for files..
also it is making comskip off...
i have one file that is 3:18 and it shows on client as 3:41:00..freezes when it gets to 3:18:00... shows correctly as 3:18 on server machine..
i checked <defaultfps>29.97000 and it is ok, and logs show correct..

if i use video library to play same file on client, the time shows correct...
maybe a fps bug in gbpvrparser? maybe reason some having problems with hd on client...[twice as bad with 60fps]

EDIT: THIS IS ALSO THE CASE ON SINGLE MACHINE WHEN VIEWING IN-PROGRESS RECORDINGS vs. AFTER RECORDING. [NO CLIENT USED AT ALL]

So it affects all recordings played thru gbpvrparser.

[sub]

I'm aware of this bug. Unfortunately there is no easy fix for this.

Its on my todo list for future release.

[pBS]

glad you know about it as it seems to be the only thing wrong...
but i think it also effects viewing in progress recordings too...makes transitions between timshifted shows sometimes hang..
will check later to see if the times are off..

just glad you are aware...it does cause odd behavior..

would filesharing mode not have this problem?

[sub]

would filesharing mode not have this problem?

I'm not sure. I've not investigated the problem yet.

[pBS]

after further investigation, it also happens on a single local instance [no client] also when viewing in-progress recordings and timeshift... gbpvrparser

i suspect the math is off for ntsc only.. the 30000/1001 ratio isn't correct or something...[it's the formula they produce with so is most accurate]
but it's also like pi an infinite number so may just need a bit more precision added...maybe a few extra digits? [like 29.97002997]
seems to be off consistantly 6 mins/hr..

i think that's why some people have timeshift transition to next program hanging...[first show 'time' reaches supposed end point before enough time has elapsed] [tho seems like you have workaround to help this,doesn't always happen to me, but increases pause between] about 10% of time it hangs going to next show..

i suspect there will be lots of weird problems that will go away with this fix...specially for client and local timeshift here in ntsc land..

looking forward to the new version for the new events, but i'd gladly wait for this one..
[seems to knock me out of t/s shows at worst times! grr]
i have to record the entire friday night because i've lost shows every time i try to just timeshift them in a row..[4 1hr shows in row]

Thanks!
you da Man!

[pBS]

time when in-progress recording...32:30
time when exit and play after.......29:53 <--actual recording time
this is just on a regular local pvrx2 session...same on client tho..

hope that helps..

[sub]

looked into this yet?

Sorry, no. I havnt looked into anything client related in this pending next release. Its still on my todo list, but it never made it high enough up the priority list.

[pBS]

but it's not just a client issue...normal timeshift and in-progress also has same problem...
if it were just client issue i wouldn't mind too much...happens regardless of decoder, system...

[pBS]

yes, this is confirmed that it's not a client issue, it's prevalent on all recordings that are in-progress...
tho i suspect it only is an issue with NTSC users...
[the floating point fps math]

it actually makes pausing livetv buggy in any scenario, while pausing works fine near beginning of timeshift file, even a few minutes into file, pausing spikes cpu to 100% and sits there, but if you pause/unpause again quickly, it plays...

this has been happening for several versions now...and is really annoying the number of timeshift sessions i've locked up because of it...or number of times the next show won't play at transition..

since i've been using the triple pause to unpause, it seems to be a workaround..
but if i let it sit after unpause...it locks pvrx2...every time...
not very good for the WAF..

as a note, this is on several machines with any combo of decoder/hardware..but always NTSC....

[sub]

Sorry, I still havnt looked into it. I kind of know what the problem is, but its not going to be an easy fix so I'm kind of opting for the head in sand technique while I'm particularly busy with my day job at the moment.