Skip to content
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

MediaInfo parser throws TypeError when parsing mp4 file #100

Closed
rhxto opened this issue Nov 23, 2020 · 9 comments
Closed

MediaInfo parser throws TypeError when parsing mp4 file #100

rhxto opened this issue Nov 23, 2020 · 9 comments

Comments

@rhxto
Copy link

rhxto commented Nov 23, 2020

Hello, I'm using the latest version of pymediainfo.
It works for all my mp4 files, except 1: windows media player is able to open it, but when I parse it with MediaInfo.parse() it raises a TypeError.

v = MediaInfo.parse("H:\\v\\ig\\:saved\\2014-02-14_05-28-26_UTC.mp4")        

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\*\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\pymediainfo\__init__.py", line 497, in parse
    return cls(info, encoding_errors)
  File "C:\Users\*\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\pymediainfo\__init__.py", line 167, in __init__
    self.tracks.append(Track(xml_track))
  File "C:\Users\*\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\pymediainfo\__init__.py", line 86, in __init__
    setattr(self, primary, int(getattr(self, primary)))
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

The problem is not with the win32 api path, because if I cd into the video's directory and execute the same command with a DOS path the same error is raised.
I'm new to python so I might have missed a stupid thing, in that case, sorry in advance :>

@sbraz
Copy link
Owner

sbraz commented Nov 23, 2020

Hi, I think I know why this happens, can you please attach the output of mediainfo.exe --output=OLDXML -f 2014-02-14_05-28-26_UTC.mp4to help me debug this?
Also please let me know if it works with pymediainfo version 4.3.

@rhxto
Copy link
Author

rhxto commented Nov 23, 2020

Sure, here is the output of that command: https://pastebin.com/c22VwSHm
Just checked and yes, it works with pymediainfo v4.3
I'll stick with that version for now.

@sbraz
Copy link
Owner

sbraz commented Nov 23, 2020

Thanks, it's a really interesting corner case caused by the Other_Format_List, Other_Format_WithHint_List, etc. attributes.

pymediainfo creates attributes named other_<attribute> when the attribute is repeated (Duration, for instance is presented in several formats, resulting in the creation of other_duration).

The problem the code believes other_format_list is linked to a format_list attribute. There is no such attribute so it fails.

I'll try to provide a fix tonight.

@rhxto
Copy link
Author

rhxto commented Nov 23, 2020

Wonderful!
Thanks for the super quick response.

You can close this issue via commit or manually, I'll leave it up to you.

sbraz added a commit that referenced this issue Nov 23, 2020
This was a regression from 099192c
when I moved away from generic exceptions. It happened when media files
contained tracks of Type "Other", resulting in attributes in "General"
such as "Other_Format_List".
sbraz added a commit that referenced this issue Nov 23, 2020
This was a regression from 099192c
when I moved away from generic exceptions. It happened when media files
contained tracks of Type "Other", resulting in attributes in "General"
such as "Other_Format_List".
sbraz added a commit that referenced this issue Nov 23, 2020
This was a regression introduced by 099192c
when I moved away from generic exceptions. It happened when media files
contained tracks of Type "Other", resulting in attributes in "General"
such as "Other_Format_List".
@sbraz
Copy link
Owner

sbraz commented Nov 23, 2020

Can you please try the typeerror branch? pip install git+https://github.com/sbraz/pymediainfo@typeerror

@rhxto
Copy link
Author

rhxto commented Nov 23, 2020

It isn't able to find some sort of library (I have no idea if this error is on my side):
Do I need to change my import in case I'm installing pymediainfo from a git branch?

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\fedeb\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\pymediainfo\__init__.py", line 421, in parse
    lib, handle, lib_version_str, lib_version = cls._get_library(library_file)
  File "C:\Users\fedeb\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\pymediainfo\__init__.py", line 323, in _get_library
    raise OSError("Failed to load library")
OSError: Failed to load library

@sbraz
Copy link
Owner

sbraz commented Nov 23, 2020

Ah you need to either copy the DLL to the pymediainfo folder, your script's folder, or somewhere listed in your PATH environment variable.

@rhxto
Copy link
Author

rhxto commented Nov 23, 2020

It works like a charm now.
Thanks for the help!

@rhxto rhxto closed this as completed Nov 23, 2020
sbraz added a commit that referenced this issue Nov 23, 2020
This was a regression introduced by 099192c
when I moved away from generic exceptions. It happened with media files
containing tracks of Type "Other", resulting in attributes such as
"Other_Format_List" in the general track.

We fix this by listing all repeated attributes instead of relying on
them starting with "other_".
@sbraz
Copy link
Owner

sbraz commented Nov 23, 2020

Glad I could help, I'm sorry about the regression, the funniest thing is that I needed a test file similar to yours to test this:

def other_tracks(self) -> List[Track]:

If I had properly tested it, I would have noticed that files with tracks of type Other were failing 😄

Anyway I've released v5.0.3 which contains the fix, enjoy!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants