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

The % symbol corrupts the filename field #163

Closed
Dude00 opened this Issue Dec 7, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@Dude00

Dude00 commented Dec 7, 2017


Should display as: South Park - S15E12 1%.mp4

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 8, 2017

Contributor

Thanks for reporting this issue. I've tested and can replicate. I will need to write some code to replace % with &percent; or similar so it displays properly (unless someone else gets to it first).

Contributor

Et0h commented Dec 8, 2017

Thanks for reporting this issue. I've tested and can replicate. I will need to write some code to replace % with &percent; or similar so it displays properly (unless someone else gets to it first).

@Et0h Et0h added the bug label Dec 8, 2017

@Et0h Et0h self-assigned this Dec 8, 2017

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 9, 2017

Contributor

Were you using MPC-HC?

I've made an initial investigation, and my best guess is that it is a MPC-HC bug rather than a Syncplay bug but it might be in the interface between the two. Can you confirm @Uriziel or @daniel-123 ?

Contributor

Et0h commented Dec 9, 2017

Were you using MPC-HC?

I've made an initial investigation, and my best guess is that it is a MPC-HC bug rather than a Syncplay bug but it might be in the interface between the two. Can you confirm @Uriziel or @daniel-123 ?

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 10, 2017

Contributor

@v0lt - I see this issue occur when using Syncplay with MPC-BE as well. Can you confirm whether or not this is an issue with the MPC-BE API and its handling of %'s?

Contributor

Et0h commented Dec 10, 2017

@v0lt - I see this issue occur when using Syncplay with MPC-BE as well. Can you confirm whether or not this is an issue with the MPC-BE API and its handling of %'s?

@albertosottile

This comment has been minimized.

Show comment
Hide comment
@albertosottile

albertosottile Dec 10, 2017

Member

On Windows 7 and MPC-HC 1.7.13 + Syncplay 1.5.0, the player crashes if I try to open a file with a '%' char in its name. Everything works fine with the same file and VLC 2.x on Windows 7 and macOS 10.12

Member

albertosottile commented Dec 10, 2017

On Windows 7 and MPC-HC 1.7.13 + Syncplay 1.5.0, the player crashes if I try to open a file with a '%' char in its name. Everything works fine with the same file and VLC 2.x on Windows 7 and macOS 10.12

@NinoM4ster

This comment has been minimized.

Show comment
Hide comment
@NinoM4ster

NinoM4ster Mar 19, 2018

Confirmed on Windows 10 x64 (1709), with MPC-HC 1.7.13 and Syncplay 1.5.2.
I tried playing a web .MKV file which contained "[ ]" on it's name and MPC-HC crashed/stopped working, but it can run the same file by itself just fine.
I solved it by replacing every " [ " with an " ( " and every " ] " with an " ) " on the file name, but haven't tested with spaces yet (which should return "%20").

NinoM4ster commented Mar 19, 2018

Confirmed on Windows 10 x64 (1709), with MPC-HC 1.7.13 and Syncplay 1.5.2.
I tried playing a web .MKV file which contained "[ ]" on it's name and MPC-HC crashed/stopped working, but it can run the same file by itself just fine.
I solved it by replacing every " [ " with an " ( " and every " ] " with an " ) " on the file name, but haven't tested with spaces yet (which should return "%20").

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h
Contributor

Et0h commented Apr 8, 2018

@albertosottile

This comment has been minimized.

Show comment
Hide comment
@albertosottile

albertosottile Apr 26, 2018

Member

@Et0h since this was proved to be a bug in MPC, should we close this?

Member

albertosottile commented Apr 26, 2018

@Et0h since this was proved to be a bug in MPC, should we close this?

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Apr 26, 2018

Contributor

It is said to be fixed in MPC-BE r3521. Closing.

Contributor

Et0h commented Apr 26, 2018

It is said to be fixed in MPC-BE r3521. Closing.

@Et0h Et0h closed this Apr 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment