New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alpine linux: Connection works with iPhone, but not with Macbook (M2 Max, macOS 14) #264
Comments
your uxplay.log shows But no video data from client ever seems to arrive at TCP port 36903. UxPlay is tested on OSX )with M2 Max, and works correctly. try the -p option to use fixed data ports. Can you test with some more standard linux (e.g arch or ubuntu) on standard hardware to rule out some
|
maybe the -fps18 is the issue? |
Thanks, Yes, |
-fps 18 tells the client that the server will not accept video at a rate greater than 18fps. It seems that your macOS M2 client system refuses to send any video at that slow rate. The default is 30fps. |
We will try to test alpine linux,,but not before next week. what processor architecture ? |
@fduncanh Thanks, I use alpine on amd64 as host. UxPlay feels lag so I want to try lower fps, uxplay works like stop a will then works again. out.mp4 |
uxplay should work without lags on amd64. Is alpine linux "friendly" in a multi-boot (multi-linux) setup (i.e. won't destroy other linux installations - this is a grub2 issue)? Is a virtualbox installation OK for testing your issues? How much memory does your amd-64 system have. how old is it (describe it more) there appear to be various modes
which one is giving you problems? |
Thanks. I use sys mode, no multi-boot (all my server are alpine), here is the neofetch output
|
we installed an alpine linux 3.19 test installation (sys mode on x86_64), with kde. running "uxplay -vs xvimagesink" (in an X11 session) triggers something (in gstreamer?) that causes PAM to immediately shutdown sddm, and terminate the user session. /var/log/messages shows:
"uxplay" by itself also does this, probably because xvimagesink is the default choice made by "autovideosink". -vs ximagesink and -vs glimagesink work. In a wayland session this also does not occur (presumably autovideosink chooses waylandsink) Another alpine SDDM weirdness (which apparently a KDE known bug in a prerelease version of SDDM, also reported in Arch Linux) is that the regular "enter" key is not recognized on the login screen, only the numeric keypad "enter" is. |
Soory to open this, I found this #73 , but already using uxplay build from master source, I don't know where to look at.
gst.log
uxplay.log
started by
uxplay -n "tv@rad-office" -nh -fps 18 -fs -vs ximagesink
The text was updated successfully, but these errors were encountered: