jeffshee
UI very slow, wallpaper improperly scaled
running on Debian. The program takes a few minutes after bootup to launch. Once open the UI is also extreamly slow to react, selecting a wallpaper and clicking apply also takes about 2-3 minutes before its actually set. But once set the scaling seems to be off, I can only see the top left quadrant of an image, no matter the actual resolution. When plugged into my dual screen dock the image is scaled appropriately on both screens
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
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`
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!
I pushed the fix just now. It should be work now. Please try to update the program by executing the installation script again.
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?
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?
I can't give you specifics, its a corp laptop, but its based on debian 10 with cinnamon. i7 with 32gb ram
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?
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
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!
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!
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%)
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. ; )
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:
- Fedora 33 (AMD CPU with Nvidia GTX1080) There is no error message printed by vlc at all.
- 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.
Closed as the new release is out. Feel free to reopen if the issue still remains.