UI very slow, wallpaper improperly scaled about hidamari HOT 15 CLOSED

I ran it with time command so you can see exactly how long it takes. the right click issue seems related to the delay, i didn't realize it was taking so long to launch so I didn't see the menu. I'm including the 2 screenshots of what it looks like and what it should look like.

in this example it autoloaded the "waves" wallpaper and i changed it to a different one "spaceman" but it doesn't really matter what I select, it behaves the same.

`~$ time hidamari
Config JSON:
{'audio_volume': 50,
'data_source': '/home/acme/Videos/Hidamari/waves1080.mp4',
'is_detect_maximized': True,
'is_mute': False,
'is_static_wallpaper': True,
'mode': 'MODE_VIDEO',
'static_wallpaper_blur_radius': 5,
'version': 2}
Mode: Video
WindowHandler: {'is_any_maximized': False, 'is_any_fullscreen': False}
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
Local Video: /home/acme/Videos/Hidamari/spaceman.mp4
Mode: Video
Player: Release
[h264 @ 0x7f1f54062200] get_buffer() failed
[h264 @ 0x7f1f54062200] thread_get_buffer() failed
[h264 @ 0x7f1f54062200] decode_slice_header error
[h264 @ 0x7f1f54062200] no frame!
WindowHandler: {'is_any_maximized': False, 'is_any_fullscreen': False}
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
Player: Quit
Save config JSON
Player: Release

real 4m26.814s
user 0m3.181s
sys 0m1.403s`

from hidamari.

I can't give you specifics, its a corp laptop, but its based on debian 10 with cinnamon. i7 with 32gb ram

from hidamari.

Hi,
Is the problem occurs only when program is launched at login? What if you kill everything and launch it manually, does the problem occurs as well?
Also, if would be helpful if you can paste the terminal output here. Also the screenshot to describe the problem better.
(How about the right click issue BTW? Are they gone?)

Thanks

from hidamari.

Hi, thanks for the screenshot!
Judging from your screenshot, I believe that you have a 4K monitor. I'm suspecting that it might be the program didn't get the your screen resolution correctly. Since it only show 1/4 of the video with your 4K screen, it probably mean that the program is trying to render the video in 4 times of the 4K resolution! And this might also explain the lag.
Although I don't have a 4K screen to test my code, I will try looking into this issue. In the meantime, you can try the following workaround that might slove the issue, if you feel adventurous! (If so please tell me if it works^^)

Open base_player.py in your favourite editor, look for these lines:

    @property
    def width(self):
        return self.gdk_monitor.get_geometry().width * self.gdk_monitor.get_scale_factor()

    @property
    def height(self):
        return self.gdk_monitor.get_geometry().height * self.gdk_monitor.get_scale_factor()

Then override your screen resolution (suppose it is 3840x2160) like this, save.

    @property
    def width(self):
        return 3840

    @property
    def height(self):
        return 2160

Thanks!

from hidamari.

I pushed the fix just now. It should be work now.
Please try to update the program by executing the installation script again.

from hidamari.

I was looking through the code but didn't see those lines. I went ahead and updated from the script, and it seems to be scaling properly now. It still takes like 2 minutes to launch but its much improved. I noticed in the console output now it reads Monitor: width 1920 height 1920 Shouldn't it say 3840 and 2160?

from hidamari.

Thanks for reporting!
Yep, it sounds weird but it is actually the correct one this time. The width and height here means the “application pixel” according to the documentation, which is already considering the scaling factor of your monitor. Apparently your scaling factor is 2, so if you times 2 to both the width and height, you will get the “device pixel” this time, which we don’t use in the code.

Alright, I will move on to test my code with Debian. Could you tell me the exact version of your OS, GNOME, etc. so that I can reproduce the issue?

from hidamari.

Hi, I tested using Debian 10 and cinnamon, but couldn't reproduce the issue that you described. I also tried the streaming function, most thing works on my side, including the GUI, right-click menu, etc.

The system that I used for testing:

Did you installed the multimedia codec? For debian, it is:
sudo apt install libavcodec-extra
Also, could you provide the output of pip3 list?

from hidamari.

BTW, these are the packages that I installed from fresh installation of Debian:

sudo apt install libavcodec-extra python3 python3-pip git ffmpeg vlc libx11-6
sudo apt install python3-gi python3-gi-cairo gir1.2-gtk-3.0
sudo pip3 install pillow pydbus python-vlc youtube-dl

from hidamari.

I'm having the same problem on a multimonitor setup. I'm using a 1080p TV and an old 1280 x 1024 VGA monitor. When i open Hidamari, after just 3-4 minutes i get

[h264 @ 0x7f1f54062200] get_buffer() failed
[h264 @ 0x7f1f54062200] thread_get_buffer() failed
[h264 @ 0x7f1f54062200] decode_slice_header error
[h264 @ 0x7f1f54062200] no frame!

and these error messages start to loop infinitely.

After reading this post i disconnected the old 1280 x 1024 monitor and it has stopped giving me that error. I'm using Fedora 34 with Nvidia 465.27 drivers on Xorg. Thought i'd post this to suggest that this is probably a screen resolution problem instead of a distro problem.

Update: forgot to mention the UI isn't slow on my case and its working as it should. Also i'm using the copr repo package instead of the master branch.

Update 2: Just tried manual instalation from master and it took like 40 minutes till the error starts looping again.

[h264 @ 0x7f1068ccb180] get_buffer() failed
[h264 @ 0x7f1068ccb180] thread_get_buffer() failed
[h264 @ 0x7f1068ccb180] decode_slice_header error
[h264 @ 0x7f1068ccb180] no frame!
[h264 @ 0x7f1068ce7f80] get_buffer() failed
[h264 @ 0x7f1068ce7f80] thread_get_buffer() failed
[h264 @ 0x7f1068ce7f80] decode_slice_header error
[h264 @ 0x7f1068ce7f80] no frame!

from hidamari.

Hi, @rgomez96
Thanks for reporting the issue.
By mentioning that you have the same problem, I believe it means the wallpaper isn't scaled properly, am I right?

So far, my system also print this kind of error message, but I think it is usually safe to ignore (since nothing actually break on my system). I think these error messages was just the debug messages printed by vlc itself. If it's causing any trouble, maybe I can try to suspress the output from vlc in the future, though it might cause difficulty in debugging.

[h264 @ 0x7f1068ccb180] get_buffer() failed
[h264 @ 0x7f1068ccb180] thread_get_buffer() failed
[h264 @ 0x7f1068ccb180] decode_slice_header error
[h264 @ 0x7f1068ccb180] no frame!

Usually these messages will only print once, when the vlc loads the video. How frequently is the looping that you mentioned? How much is the length of your video? (I can test it on my system if you could provide me the video)

The COPR doesn't update that frequently, so I would suggest you to use the master branch to receive bug fix sooner :)
BTW, for Fedora, the required video acceleration driver isn't come out of the box due to licensing. If your CPU usage is high, that's probably means that you are rendering on CPU. Consider install the required driver from rpmfusion then. ;)

# Video acceleration Intel
sudo dnf install libva-intel-driver libva-intel-hybrid-driver
# Video acceleration AMD/NVIDIA
sudo dnf install libvdpau-va-gl

Thanks!

from hidamari.

Yes, my video wallpapers are all either 1080p or 720p, since the second monitor is 1280 x 1024 (more like a square) i get black bars on the top and the bottom but the wallpaper is displayed completely.

It's also true that this error

[h264 @ 0x7f1068ccb180] get_buffer() failed [h264 @ 0x7f1068ccb180] thread_get_buffer() failed [h264 @ 0x7f1068ccb180] decode_slice_header error [h264 @ 0x7f1068ccb180] no frame!

appears from time to time only once and nothing really happens, it's only after a while that the error starts to repeat itself infinitely and the program stops working completely. If i have the GUI open it freezes completely and the process wont end by using SIGTERM on htop. If i try to start hidamari again i get 'Error: Failed to create server
' (i guess i get that because it is already running, it makes sense).

I've tested some different videos and i get this problem on all of them so i wouldnt think some video is the problem and video acceleration works. My CPU usage is low (though the GPU usage is kinda high, usually around 60%).

If it counts, here's the output of vainfo and vdpauinfo

vainfo:

libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.11.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG4Simple            :	VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    :	VAEntrypointVLD
      <unknown profile>               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD

vdpauinfo:

display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  465.27  Thu Apr 22 23:11:23 UTC 2021

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12 
422     4096  4096  UYVY YUYV 
444     4096  4096  NV24 YV24 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                           0 65536  4080  4080
MPEG2_SIMPLE                    3 65536  4080  4080
MPEG2_MAIN                      3 65536  4080  4080
H264_BASELINE                  51 65536  4096  4096
H264_MAIN                      51 65536  4096  4096
H264_HIGH                      51 65536  4096  4096
VC1_SIMPLE                      1  8190  2048  2048
VC1_MAIN                        2  8190  2048  2048
VC1_ADVANCED                    4  8190  2048  2048
MPEG4_PART2_SP                  3  8192  2048  2048
MPEG4_PART2_ASP                 5  8192  2048  2048
DIVX4_QMOBILE                   0  8192  2048  2048
DIVX4_MOBILE                    0  8192  2048  2048
DIVX4_HOME_THEATER              0  8192  2048  2048
DIVX4_HD_1080P                  0  8192  2048  2048
DIVX5_QMOBILE                   0  8192  2048  2048
DIVX5_MOBILE                    0  8192  2048  2048
DIVX5_HOME_THEATER              0  8192  2048  2048
DIVX5_HD_1080P                  0  8192  2048  2048
H264_CONSTRAINED_BASELINE      51 65536  4096  4096
H264_EXTENDED                  51 65536  4096  4096
H264_PROGRESSIVE_HIGH          51 65536  4096  4096
H264_CONSTRAINED_HIGH          51 65536  4096  4096
H264_HIGH_444_PREDICTIVE       51 65536  4096  4096
VP9_PROFILE_0                  --- not supported ---
VP9_PROFILE_1                  --- not supported ---
VP9_PROFILE_2                  --- not supported ---
VP9_PROFILE_3                  --- not supported ---
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y 

It's a GTX 750ti using the propietary driver.

EDIT: Forgot to add that when the software fails and errors start looping (and i mean seriously looping i get nothing but the error) CPU usage skyrockets and starts to use 50% of my CPU. (2 processes on HTOP using 100% of my CPU, i have 4 threads to i guess 50%)

from hidamari.

HI, @rgomez96
Thanks for reply.
I will keep Hidamari running with the GUI opened and leave it for few hours now.
I'm also using Fedora and Nvidia GPU, we are having a quite similar setup here.
I will see if I can reproduce the issue on my side. ; )

from hidamari.

Hi, @rgomez96
I had tested using 2 PC, one is Fedora 33 (AMD CPU with Nvidia GTX1080), another one is Fedora 34 (Intel CPU with Nvidia GTX950M, an optimus laptop), both is running fine on my side. I keep Hidamari running for few hours as suggested, and here is the result:

1. Fedora 33 (AMD CPU with Nvidia GTX1080)
   There is no error message printed by vlc at all.
2. Fedora 34 (Intel CPU with Nvidia GTX950M, an optimus laptop)
   There is error message printed by vlc, but only at the beginning when the video load. The looping of error messages mentioned didn't happen though.

I couldn't reproduce the issue on my side, so I'm not sure what's causing the problem. Your output of vainfo and vdpauinfo seem totally fine.

Also, your issue seems to be different from OP. So I will create a new issue and reference this to there.

from hidamari.

Closed as the new release is out. Feel free to reopen if the issue still remains.

from hidamari.