Notification window while flushing data to disk.

[Aditya V]

This is more of a feature request than a bug report.

When I stop recording in Kazam, it seems like it's not doing anything. Once, I closed Kazam because I thought it wasn't doing anything (and got very mad...), and, therefore, I lost my recording. I tried this again (on a long video), and I thought it wasn't doing anything again (and got mad... again). Then, I simply waited for a little bit. Suddenly, Kazam popped up asked what I should do with the video (e.g. save for later use, etc.).

I think Kazam should say that it's processing the video during this massive time gap so people like me won't get mad and close it while it's about to prompt me to save my video. Also, I'm pretty sure this is only for really long videos (e.g. 20 min-1 hr), not short 1-minute ones.

Thanks in advance!

[David Klasinc (bigwhale)]

You are correct. This happens when you record longer videos and it takes some time for GStreamer to flush all the data from memory to disk.

I'll implement some sort of "Please wait" notification before I display Done Recording window.

[David Klasinc (bigwhale)]

I have an additional question. Is this happening with H264 and VP8 videos?

[Aditya V (kroq-gar78)]

If you mean Matroska and WebM, yes.

On Tue, Mar 27, 2012 at 1:06 AM, David Klasinc <email address hidden> wrote:

> I have an additional question. Is this happening with H264 and VP8
> videos?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/945958
>
> Title:
> Notification window while flushing data to disk.
>
> Status in Kazam Screencaster:
> Confirmed
>
> Bug description:
> This is more of a feature request than a bug report.
>
> When I stop recording in Kazam, it seems like it's not doing anything.
> Once, I closed Kazam because I thought it wasn't doing anything (and
> got very mad...), and, therefore, I lost my recording. I tried this
> again (on a long video), and I thought it wasn't doing anything again
> (and got mad... again). Then, I simply waited for a little bit.
> Suddenly, Kazam popped up asked what I should do with the video (e.g.
> save for later use, etc.).
>
> I think Kazam should say that it's processing the video during this
> massive time gap so people like me won't get mad and close it while
> it's about to prompt me to save my video. Also, I'm pretty sure this
> is only for really long videos (e.g. 20 min-1 hr), not short 1-minute
> ones.
>
> Thanks in advance!
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kazam/+bug/945958/+subscriptions
>

[CheolHan Yoon (mait)]

If flushing(encoding?) time is so long, it would be better show progress bar popup.

Notification is short. User would wonder when this operation end.

IMO, progress bar is better for UX.

[Aditya V (kroq-gar78)]

Yes, I agree with mait. It should be a progress bar instead of a notification for long dumps if possible.

Sincerely,
kroq-gar78

[Alan Pope 🍺🐧🐱 🦄 (popey)]

I am inclined to agree that a post-processing percentage bar would be 'nice to have'. I would also like it to 'fail safe'. If the encoding fails part way through (system overheats, crashes, battery fails, disk out of space) then the original recording should be intact and there should be _some_ way to re-process it. I don't think it's something that happens often enough to require a GUI option to do, but it would be nice if there was a little shell script in the package which did a recovery. Or even nicer would be if kazam on startup detected the existence of a movie that hadn't been processed and offered to reprocess it.

[Aditya V (kroq-gar78)]

Do you mind if I attempt at solving this bug?

[David Klasinc (bigwhale)]

The problem with flushing data to disk happens after Gstreamer already stopped recording. It needs some time to process all the data. Progress bar about this is only possible if Gstreamer has an API for that and is available in pygst. I'll have to look into this and/or ask about it on Gstreamer mailing list.

Alan, data recovery could be possible, but videos would all be without headers. I like the idea of recovery on startup. I'll think about this.

kroq-gar, I don't mind it at all, so if you propose a patch, I'll gladly include it.

[CheolHan Yoon (mait)]

If so hard to get progress info, How about this strategy?

 - User clicks 'Finish'
 - Notify message about 'In progress'
 - At the same time, change indicator icon state to something 'animated'
   while in progress. Like network-manger icon.
 - Notify message 'finish' and change icon to normal.

The point is user should know about kazam's current state. Just notifying
one time is not good for this situation.

2012/4/10 David Klasinc <email address hidden>:
> The problem with flushing data to disk happens after Gstreamer already
> stopped recording. It needs some time to process all the data. Progress
> bar about this is only possible if Gstreamer has an API for that and is
> available in pygst. I'll have to look into this and/or ask about it on
> Gstreamer mailing list.
>
> Alan, data recovery could be possible, but videos would all be without
> headers. I like the idea of recovery on startup. I'll think about this.
>
> kroq-gar, I don't mind it at all, so if you propose a patch, I'll gladly
> include it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/945958
>
> Title:
>  Notification window while flushing data to disk.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kazam/+bug/945958/+subscriptions

--
Mait

[David Klasinc (bigwhale)]

Mait, I have no idea how hard it is to get the progress info. I don't even know if this information is available. I haven't looked into it yet.

Kroq-gar os apparently looking into it. :)

[David Klasinc (bigwhale)]

I did a little research on this, queue's have internal buffers but they aren't that big and they shouldn't create so much lag. You could monitor queue properties 'current-level-buffers' or 'current-level-bytes'.

[David Klasinc (bigwhale)]

I pushed new changes to the unstable version, a little speed and latency tweak. I recorded 18 minutes of video in VP8 that was 162MB in length. When I stopped the recording the done recording dialog popped up instantly with no wait.

However, this is in the unstable branch.

[CheolHan Yoon (mait)]

I tried dev branch version.

bzr branch lp:kazam
(close current running kazam process)
cd kazam/bin
./kazam

20 min, 147MB recorded. About 40 secs to get popup for save file.

[David Klasinc (bigwhale)]

Bummer, I wish I could reproduce this.

[David Klasinc (bigwhale)]

I was testing this on my notebook again with the unstable release and I had no performance issues.

Mait, what kind of a computer are you using? Graphics card, CPU, RAM?

[CheolHan Yoon (mait)]

Works fine (trunk rev. 193).

But VP8 still choppy than H.264.

2012/4/18 David Klasinc <email address hidden>:
> I was testing this on my notebook again with the unstable release and I
> had no performance issues.
>
> Mait, what kind of a computer are you using? Graphics card, CPU, RAM?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/945958
>
> Title:
>  Notification window while flushing data to disk.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kazam/+bug/945958/+subscriptions

--
Mait

[k-m (k-m)]

I had a question, is there any where I can recover recordings?

[David Klasinc (bigwhale)]

I just tested this with 1.3.3 version and flush is immediate with VP8 and H264 codecs.