Code: Select all
python get-pip.py
Are you setting the monitor resolution manually in config.txt using framebuffer_width and framebuffer_height? If so, use hdmi_group and hdmi_mode instead to set monitor resolution instead and reboot. If that doesn't work try disabling overscan using disable_overscan=1 and reboot. See: https://www.raspberrypi.org/documentati ... fig-txt.md for details on how to do this.Pearl.852 wrote:But I found a problem where the actual video playing area is shifted up and to the left away from the player window.
It isn't programmed to toggle like that at the moment but i'll add that to my "to do" list.Pearl.852 wrote:When click on the Play/Pause (||) button, the video pauses, but the icon did not change to (>) as I expect it would.
What OS are you using? I'll try to reproduce this bug and get back to you.Pearl.852 wrote:When use the Space Bar on the keyboard to pause the playing, the video did not pause but just flicker. Pressing the Space Bar again did not recover and eventually the monitor (HDMI) shows "No signal", only pressing the Esc key will recover and resumes playing.
Can you open a terminal and type in "omxplayer your_file.mp4" and tell me if the file plays or post the output that's printed to screen if it doesn't? Also can you post the actual name of the mp4 file here eg: "best_movie.mp4" so I can test to see why the scanner is not picking it up. Thanksjimjulian wrote:I tried to play an .mp4 video, but the scanner would not recognize the file. Will Ubeify eventually play the popular .mp4 format? ... a local scan will not recognize an mp4 video file.
Unfortunately there is no work around that I know of to make that work.jimjulian wrote:I can use Microsoft Remote Desktop to run the Raspbian desktop. When I run the desktop and play a feed music file, there's no audio. Is there a work around for that?
You are right about the overscan settings. Tried disabling overscan and that fixed the problem. However, my TV Monitor requires using the overscan settings in order to display the desktop properly.KTWS wrote:Are you setting the monitor resolution manually in config.txt using framebuffer_width and framebuffer_height? If so, use hdmi_group and hdmi_mode instead to set monitor resolution instead and reboot. If that doesn't work try disabling overscan using disable_overscan=1 and reboot. See: https://www.raspberrypi.org/documentati ... fig-txt.md for details on how to do this.Pearl.852 wrote:But I found a problem where the actual video playing area is shifted up and to the left away from the player window.
Code: Select all
$ tvservice -n
device_name=GSM-2D_FHD_LG_TV
$ tvservice -s
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
Thank you.KTWS wrote:It isn't programmed to toggle like that at the moment but i'll add that to my "to do" list.Pearl.852 wrote:When click on the Play/Pause (||) button, the video pauses, but the icon did not change to (>) as I expect it would.
I am running Raspbian-Jessie. Tried reproduce this problem today and the symptom has changed after reinstalling Ubeify (Reason explain on a new post reply below). Now, pressing the Spacebar will restart the video at the beginning.KTWS wrote:What OS are you using? I'll try to reproduce this bug and get back to you.Pearl.852 wrote:When use the Space Bar on the keyboard to pause the playing, the video did not pause but just flicker. Pressing the Space Bar again did not recover and eventually the monitor (HDMI) shows "No signal", only pressing the Esc key will recover and resumes playing.
Ubeufy uses a pip installation of youtube-dl; this may conflict with the github version (optionally) used by omxplayerGUI. ubeify should check if the github version is installed and use that or include it's own version and set the import path accordingly. A pip install may also conflict with the universal install (fake binary with zipped modules).Pearl.852 wrote:On Raspbian-Jessie, Ubeify will break after installing OMXPlayerGUI. Reinstalling Ubeify then both apps will work properly.
omxplayerGUI is using a non-mainstream youtube-dl install method which, by the looks of things, breaks previous installations using official github readme methods. You may want to fix that, or if it's not your fault, report it as an issue on github. Regardless of where fault lies, omxplayerGUI breaking other software is unacceptable.gkreidl wrote:Ubeify uses a pip installation of youtube-dl; this may conflict with the github version (optionally) used by omxplayerGUI.
Ubeify imports youtube-dl as an actual python module (it's faster for multiple queries) so installing it via the official pip method is the correct way to install it. Ubeify can't check to see if the github version is installed because the version of youtube-dl installed via pip is the uncompressed github version. They are both identical.gkreidl wrote:ubeify should check if the github version is installed and use that or include it's own version and set the import path accordingly.
There is no conflict. pip installs an uncompressed version of youtube-dl so, if the fake binary is already installed, it's simply overwritten. No break in functionality. If the fake binary version of youtube-dl is installed after Ubeify is installed, the only file that changes is the youtube-dl /usr/bin/ file (for command line usage) which Ubeify does not use. No break in functionality although the fake binary will be overwritten next time pip updates youtube-dl.gkreidl wrote:A pip install may also conflict with the universal install (fake binary with zipped modules).
My guess is Raspberry Pi's firmware ignores overscan settings when reporting the GPU layer screen size. I should be able to push a workaround Ubeify fix but it may take me a couple of days. It would be very helpful if you could post your full /boot/config.txt file here, thanksPearl.852 wrote:You are right about the overscan settings. Tried disabling overscan and that fixed the problem. However, my TV Monitor requires using the overscan settings in order to display the desktop properly.Code: Select all
$ tvservice -n device_name=GSM-2D_FHD_LG_TV $ tvservice -s state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
The problem is the following and I discovered it after reporting an issue to youtube-dl developers. I had the compressed version installed. They fixed the bug and told me to update youtube-dl ( the -U command). Afterwards it did not work. We got into quite a discussion. At the end they asked me to to check, if I had an old version in my Python path. That was it. After removing the version from the Python path, the bug was fixed.KTWS wrote:omxplayerGUI is using a non-mainstream youtube-dl install method which, by the looks of things, breaks previous installations using official github readme methods. You may want to fix that, or if it's not your fault, report it as an issue on github. Regardless of where fault lies, omxplayerGUI breaking other software is unacceptable.gkreidl wrote:Ubeify uses a pip installation of youtube-dl; this may conflict with the github version (optionally) used by omxplayerGUI.Ubeify imports youtube-dl as an actual python module (it's faster for multiple queries) so installing it via the official pip method is the correct way to install it. Ubeify can't check to see if the github version is installed because the version of youtube-dl installed via pip is the uncompressed github version. They are both identical.gkreidl wrote:ubeify should check if the github version is installed and use that or include it's own version and set the import path accordingly.There is no conflict. pip installs an uncompressed version of youtube-dl so, if the fake binary is already installed, it's simply overwritten. No break in functionality. If the fake binary version of youtube-dl is installed after Ubeify is installed, the only file that changes is the youtube-dl /usr/bin/ file (for command line usage) which Ubeify does not use. No break in functionality although the fake binary will be overwritten next time pip updates youtube-dl.gkreidl wrote:A pip install may also conflict with the universal install (fake binary with zipped modules).
The only changes that I have made to the /boot/config.txt is adding a section that is specific to my TV monitor (LG 24MT55D) as below,KTWS wrote:My guess is Raspberry Pi's firmware ignores overscan settings when reporting the GPU layer screen size. I should be able to push a workaround Ubeify fix but it may take me a couple of days. It would be very helpful if you could post your full /boot/config.txt file here, thanksPearl.852 wrote:You are right about the overscan settings. Tried disabling overscan and that fixed the problem. However, my TV Monitor requires using the overscan settings in order to display the desktop properly.Code: Select all
$ tvservice -n device_name=GSM-2D_FHD_LG_TV $ tvservice -s state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
Code: Select all
[EDID=GSM-2D_FHD_LG_TV]
# settings here applied only when connected to LG-24MT55 monitor
disable_overscan=1
overscan_left=40
overscan_right=40
overscan_top=24
overscan_bottom=24
[all]
Code: Select all
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=48
#overscan_right=48
#overscan_top=48
#overscan_bottom=48
[EDID=GSM-2D_FHD_LG_TV]
# settings here applied only when connected to LG-24MT55 monitor
disable_overscan=1
overscan_left=40
overscan_right=40
overscan_top=24
overscan_bottom=24
[all]
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
#dtoverlay=vc4-kms-v3d
gpu_mem=128
Users browsing this forum: No registered users and 9 guests