Ok, so I don't know if these are the only issues, but here is what I have figured out so far:
1) Seeking past the end of the clip (via the Skip buttons) isn't supposed to restart the clip unless you have "Loop" enabled. That is a bug and I can fix it easily.
2) Seeking (skipping ahead or back is seeking too) is inaccurate if UI3 and Blue Iris disagree about how long the clip is. The bigger the disagreement, the worse it gets. Unfortunately, this turns out to happen extremely easily. When you play a clip through the web interface, Blue Iris creates a player instance in memory that knows the duration of the clip at the moment when playback started. As the clip lengthens, UI3 often learns about the new duration via automatic clip list updates. However Blue Iris's player instance does not learn about the new duration. Therefore, we get further and further out of sync for as long a the clip is recording and UI3 is hearing about it via its automatic clip list updates. We can also start out of sync if you open a clip at a time that UI3's information about the clip is stale. UI3 might think a clip is 30 minutes long but Blue Iris knows it is 60 minutes long, so you try to seek to the midway point (15 minutes in) and Blue Iris does that and says to UI3 "okay, we 25% of the way through the clip" and UI3 is like "okay, 25% of 30 minutes is 7.5 minutes" so UI3 shows the seek bar at the 25% mark and the playback clock at 7.5 minutes.
This issue has always been around, but it became a lot more noticeable after I added the "skip ahead/back 1 frame" feature. For reasons of precision, I had to change H.264 stream requests from requesting the stream by % offset to requesting the stream by millisecond offset, and this is what makes the seek bar jump to the wrong spot after you seek.
-----------
This isn't going to be easy to fix properly. The mobile apps avoid this problem by not knowing or caring how many milliseconds into a clip you are, and not knowing or caring how long the clip is. UI3 doesn't have that option... I'd have to sacrifice the playback clock and skip ahead/back functions while using the H.264 player.
I'll try to discuss this with Ken.
1) Seeking past the end of the clip (via the Skip buttons) isn't supposed to restart the clip unless you have "Loop" enabled. That is a bug and I can fix it easily.
2) Seeking (skipping ahead or back is seeking too) is inaccurate if UI3 and Blue Iris disagree about how long the clip is. The bigger the disagreement, the worse it gets. Unfortunately, this turns out to happen extremely easily. When you play a clip through the web interface, Blue Iris creates a player instance in memory that knows the duration of the clip at the moment when playback started. As the clip lengthens, UI3 often learns about the new duration via automatic clip list updates. However Blue Iris's player instance does not learn about the new duration. Therefore, we get further and further out of sync for as long a the clip is recording and UI3 is hearing about it via its automatic clip list updates. We can also start out of sync if you open a clip at a time that UI3's information about the clip is stale. UI3 might think a clip is 30 minutes long but Blue Iris knows it is 60 minutes long, so you try to seek to the midway point (15 minutes in) and Blue Iris does that and says to UI3 "okay, we 25% of the way through the clip" and UI3 is like "okay, 25% of 30 minutes is 7.5 minutes" so UI3 shows the seek bar at the 25% mark and the playback clock at 7.5 minutes.
This issue has always been around, but it became a lot more noticeable after I added the "skip ahead/back 1 frame" feature. For reasons of precision, I had to change H.264 stream requests from requesting the stream by % offset to requesting the stream by millisecond offset, and this is what makes the seek bar jump to the wrong spot after you seek.
-----------
This isn't going to be easy to fix properly. The mobile apps avoid this problem by not knowing or caring how many milliseconds into a clip you are, and not knowing or caring how long the clip is. UI3 doesn't have that option... I'd have to sacrifice the playback clock and skip ahead/back functions while using the H.264 player.
I'll try to discuss this with Ken.