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
[BUG] Windows下无法正常启动(Unable to start on Windows) #14
Comments
Same question on windows 11 21H2
Log
By the way I think it has nothing to do with python version |
It seems that this is similar to win11 启动后无法投屏 Yes, this problem is not related to the local python version The log indicates that Macast exited for some reasons when it was just starting even before the initialization was completed. Because I removed some logs that I thought will not have errors, it is regrettable that it is difficult to obtain more meaningful information from the log. I will improve the log output of the program tomorrow. hope this can help solve the bug. |
Remove all Python instances from PATH yields this (I was surprised that I have 6 Python on my PC):
The order of error messages is different (but consistently different) |
Someone remind me that the application crash are caused by the failure of MPV to run on win11. I use MPV 0.33.0 in Macast. Can you test whether this version of MPV can run on your computer? |
The package you provided works normally on my machine, at least when launched normally. However, I don't know the status of IPC, which might be the problem. |
The Lines 97 to 100 in 17f003c
which should be safe to ignore (malformed packets from the network)? Now I wonder why MPV is being commanded to stop even before it is started (the message For reference, a correct startup should look like this (captured on another 21H1 system):
|
This line is caused by the closing of the SSDP thread, because the SSDP thread will be blocked while waiting to receive data, which will cause a random delay when closing this thread. Therefore, before closing the thread, I sent an empty packet to wake up the blocked thread. Check the 1068 port of your system, Macast uses port 1068 for HTTP service. Check whether other devices can access http://[your computer's IP]:1068, such as http://192.168.1.101:1068 In my PC: C:\Users\25530>netstat -ano | findstr 1068
TCP 0.0.0.0:1068 0.0.0.0:0 LISTENING 2140
C:\Users\25530>netstat -ano | findstr 1900
UDP 0.0.0.0:1900 *:* 2140
UDP [::1]:1900 *:* 6212
UDP [fe80::9c2e:af8d:2cb5:11ad%6]:1900 *:* 6212
C:\Users\25530>tasklist | findstr 2140
Macast-v0.5.exe 2140 Console 1 59,600 K
C:\Users\25530>tasklist | findstr 6212
svchost.exe 6212 Services 0 7,216 K |
You can try this build: https://github.com/xfangfang/Macast/actions/runs/1162138219 This version add more logs, which may help solve the problem |
It seems that listening has failed, but I can do |
I still feel that some services on your system already used port 1068. try this ? netstat -ano | findstr 1068 |
That command outputs nothing. |
I wonder if this can solve your problem: https://bbs.csdn.net/topics/391900623 |
I ran into this last weekend when writing my own SSDP/DLNA implementation in Rust for a smart speaker, and I'm pretty sure that I have fixed this problem (Python gives 10013 instead of 10048 in this case). It's not this. |
This build adds HTTP port checking. If there is a port conflict, it will automatically switch to an available port. |
Do you have time to test the new release? I feel this problem has been fixed. |
It no longer crashes, but can not be searched by Bilibili (both live and video)
|
There may be many reasons why Macast cannot be searched. After the recent update(v0.6.1), there is almost no bug feedback about this. |
Because the original problem has been solved, closing this issue now. |
Versions
Bug recurrence
Just start it.
Additional information
I have Python 3.9.2 (accessible via
python
) on this machine, maybe it is related?Log
PasteBoard
The text was updated successfully, but these errors were encountered: