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

Pupil Player crashes while exporting long recordings #2076

Open
thomasf4231 opened this issue Dec 15, 2020 · 2 comments
Open

Pupil Player crashes while exporting long recordings #2076

thomasf4231 opened this issue Dec 15, 2020 · 2 comments

Comments

@thomasf4231
Copy link

Hey,
I am exporting data on pupil player for a study and on recordings with a length of about 1-40 minutes everything works fine and my data gets exported. But when I try to export data of recordings which are longer than 45 or 50 minutes, pupil player crashes with the error note attached below (on all of my recordings with such a long recording time).

I would like to ask if someone has an idea why this happens and if I could avoid it somehow. I also tried just exporting one plugin at a time but when I export just the fixation detector plugin it always crashes.
My idea was that this happened because my PC is not powerful enough (if so, do you think it most likely because of the CPU, GPU or RAM?) or that there could be a problem which is not related to my PC specs but for example to the Pupil labs program - I am asking for your experience/help because I would like to avoid buying an expensive very high spec PC if it would be for nothing.

Thank you very much in advance!

                                      player - [INFO] launchables.player: Created export dir at 

"D:\MICWS2021\AHIS11\PC1\AHIS11T8APC1\exports\001"

Traceback (most recent call last):

File "main.py", line 386, in

File "site-packages\PyInstaller\loader\rthooks\pyi_rth_multiprocessing.py", line 43, in _freeze_support

File "multiprocessing\spawn.py", line 105, in spawn_main

File "multiprocessing\spawn.py", line 115, in _main

EOFError: Ran out of input

player - [ERROR] launchables.player: Process Player crashed with trace:

Traceback (most recent call last):

File "launchables\player.py", line 594, in player

File "shared_modules\observable.py", line 247, in call

File "shared_modules\surface_tracker\surface_tracker_offline.py", line 521, in on_notify

File "shared_modules\surface_tracker\background_tasks.py", line 238, in get_export_proxy

File "shared_modules\background_helper.py", line 49, in init

File "multiprocessing\process.py", line 105, in start

File "multiprocessing\context.py", line 322, in _Popen

File "site-packages\PyInstaller\loader\rthooks\pyi_rth_multiprocessing.py", line 71, in init

File "multiprocessing\popen_spawn_win32.py", line 65, in init

File "multiprocessing\reduction.py", line 60, in dump

OSError: [Errno 22] Invalid argument

[player - [INFO] launchables.player: Process shutting down.

11352] Failed to execute script main

@adFrank
Copy link

adFrank commented Jan 7, 2021

Hey everyone,
I keep having the exact same issue and error log. The world video is exported without error for recordings of a duration below 75 minutes. However two of my recordings are 79 and 87 minutes long and their world video export crash exactly in the way described by @thomasf4231
Eye videos are exported perfectly, though.
Is there any update on this? Could this possibly be related to RAM or free disk space on the exporting device?
Any help is appreciated.
Thanks in advance

EDIT:
I can confirm that this issue relates to the hardware specs of the exporting machine. Just tested on a device with 32 GB RAM, Intel Xeon 3.5 GHz CPU and 500 GB free disk space and the world video is exported without any problem.

@papr
Copy link
Contributor

papr commented Mar 2, 2021

Player uses a background process to create the world video export. This process needs access to pupil and gaze data. On Windows, new processes need to be spawned. This means that Python creates a fresh process, pickles the necessary data, and transfers it via multiprocessing messaging. It looks like the data being transmitted is too large to be pickled. Unfortunately, this is difficult to catch as it is, based on your report, dependent on the available resources and the actual exception is very generic.

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

3 participants