Hi - I can reproduce the plasmashell bug that is linked to there, but I can't reproduce what's being reported here, interestingly - tried on a KDE Neon VM and on my regular Fedora KDE 41 device.

Weird question, but how much RAM do you have, and what graphics card/drivers do you have? I'm asking because when I tried to reproduce on the VM - with no graphics acceleration, since I haven't figured out how to get that to work with my Nvidia hardware - nothing unusual happened, Spectacle instantly responded to clicking the red tray icon, and everything acted normal.

However, on my actual "bare metal" device, Spectacle did take about 30-45 seconds to stop, output the message below to the journal, and used about 25% of total CPU capacity and 13GB of RAM before completing the file save. Total wild guess, but I'm wondering if Spectacle is getting killed by an out-of-memory situation on your device? (I'm fortunate enough to have 32GB of RAM, so it might have been able to survive on my end?)

Journal message: qt.multimedia.ffmpeg.mediadataholder: AVStream duration -9223372036854775808 is invalid. Taking it from the metadata

(In reply to John Kizer from comment #1)
> Hi - I can reproduce the plasmashell bug that is linked to there, but I
> can't reproduce what's being reported here, interestingly - tried on a KDE
> Neon VM and on my regular Fedora KDE 41 device.
> 
> Weird question, but how much RAM do you have, and what graphics card/drivers
> do you have? I'm asking because when I tried to reproduce on the VM - with
> no graphics acceleration, since I haven't figured out how to get that to
> work with my Nvidia hardware - nothing unusual happened, Spectacle instantly
> responded to clicking the red tray icon, and everything acted normal.
> 
> However, on my actual "bare metal" device, Spectacle did take about 30-45
> seconds to stop, output the message below to the journal, and used about 25%
> of total CPU capacity and 13GB of RAM before completing the file save. Total
> wild guess, but I'm wondering if Spectacle is getting killed by an
> out-of-memory situation on your device? (I'm fortunate enough to have 32GB
> of RAM, so it might have been able to survive on my end?)
> 
> Journal message: qt.multimedia.ffmpeg.mediadataholder: AVStream duration
> -9223372036854775808 is invalid. Taking it from the metadata

I have a dell XPS 9510 with 32gb of RAM and an nvidia gpu. I have the nvidia gpu setup within fedora however it only kicks in for certain tasks. If someone could point me in the right direction, I'm happy to experiment and provide logs if it helps.

Got it - we have very similar setups (same RAM amount, Nvidia cards)! If you would be able to provide the system journal logs from when this occurs on your device, that would likely be a good next step. Thanks!

When you say it gets cut short, do you get an error message or does it simply produce a video that ends early?

I am unable to reproduce the plasmashell bug, so I'm unable to follow the provided instructions.

Created attachment 177454 [details]
journal logs

Sorry for the delay. I've just tried reproducing the issue a few times. I can still replicate the plasma shell bug, however the spectacle recording no longer gets cut short. However after clicking the red icon tray icon to stop the spectacle screen recording, it still takes minutes for the red icon to disappear and for the screen recording to show up in the screencasts directory.

I see the same behaviour even if I don't replicate the plasma shell bug. Simply stopping any screen recording session takes a long time.

I've captured journal logs after recording for 12 seconds. I didn't recreate the plasmshell bug. I simply started recording, moved a window and the cursor around and then stopped the recording by clicking on the red circle in the icon tray. The red circle stayed there for around 1 minute before the recording showed up in the screencast folder.

If I try to interact with the spectacle window during this time it becomes unresponsive. Spectacle during this time is consuming 7GB+ of RAM.

Attached are my journal logs covering the entire recording session. The produced webm file shows a created timestamp of "Friday 17 January 2025 12:01:10 Eastern European Standard Time" and is named "Screencast_20250117_115930.webm".

I'm happy to perform any specific testing that you'd like. I guess that this bug could also be closed and I can reopen as a new one since the plasmashell bug doesn't need to be replicated for this issue to appear.

(In reply to Noah Davis from comment #4)
> When you say it gets cut short, do you get an error message or does it
> simply produce a video that ends early?
> 
> I am unable to reproduce the plasmashell bug, so I'm unable to follow the
> provided instructions.

It was producing a video that ended early with no error message. However I can't seem to replicate this anymore. However the hanging on screen recording being finished is happening with or without the plasma shell bug being replicated.

This might have evolved enough for me to start a new bug report, I'm happy to do whatever you all prefer.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

> Simply stopping any screen recording session takes a long time.

While minutes would seem unusual for me who has a strong CPU and an SSD, it is expected that ending the recording is not quick. There just isn't functionality in KPipeWire at the moment to alert the user that the video is being processed. The processing that occurs after the recording ends is actually necessary to keep the video from being cut short.

> This might have evolved enough for me to start a new bug report, I'm happy to do whatever you all prefer.

I would say that the slow speed or lack of feedback to the user about what is happening is a different issue.

(In reply to Noah Davis from comment #8)
> > Simply stopping any screen recording session takes a long time.
> 
> While minutes would seem unusual for me who has a strong CPU and an SSD, it
> is expected that ending the recording is not quick. There just isn't
> functionality in KPipeWire at the moment to alert the user that the video is
> being processed. The processing that occurs after the recording ends is
> actually necessary to keep the video from being cut short.
> 
> > This might have evolved enough for me to start a new bug report, I'm happy to do whatever you all prefer.
> 
> I would say that the slow speed or lack of feedback to the user about what
> is happening is a different issue.

Ok I'll do more testing and open a relevant bug report. This one can be closed