Something went wrong when loading GPX

[narfel]

Hi, can someone help me getting this to run in native windows? All dependecies and venv work, but if i pass a gpx dir (that confirmed works on linux) i get the above error.The error is in track.py:76 `except Exception as e:

raise TrackLoadError("Something went wrong when loading GPX.") from e` Sadly that doesn't tell me much.

If i remove the exception, I end up with an assertion error in create_poster-script.py:11, in <module> load_entry_point('gpxtrackposter==0.1', 'console_scripts', 'create_poster')() I'm not familiar with all that build framework around that script so any help or pointers would be appreciated, because i think it's not an issue with the script itself or gpxpy.

[flopp]

Thank you for reporting this issue. I'm Linux-only, so I cannot help much...

[yihong0618]

@narfel Which python version did you use? And can you offer some screen shot or something ?

[narfel]

This is the output i get when i remove the exception. Python version in the venv is 3.8.2. I am not familiar with that toolchain used, so i had to be creative and change it in the site-packages after build.

concurrent.futures.process._RemoteTraceback: """ Traceback (most recent call last): File "C:\Python\lib\concurrent\futures\process.py", line 239, in _process_worker r = call_item.fn(*call_item.args, **call_item.kwargs) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\track_loader.py", line 36, in load_gpx_file t.load_gpx(file_name, timezone_adjuster) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\track.py", line 69, in load_gpx self._load_gpx_data(gpxpy.parse(file), timezone_adjuster) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\track.py", line 132, in _load_gpx_data self.set_start_time(timezone_adjuster.adjust(self.start_time(), latlng)) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\timezone_adjuster.py", line 26, in adjust assert cls._timezonefinder AssertionError """ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "c:\users\narfel\gitrepos\windows\GpxTrackPoster\venv\Scripts\create_poster-script.py", line 11, in load_entry_point('gpxtrackposter==0.1', 'console_scripts', 'create_poster')() File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\cli.py", line 217, in main tracks = loader.load_tracks(args.gpx_dir) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\track_loader.py", line 109, in load_tracks loaded_tracks = self._load_tracks(remaining_file_names, timezone_adjuster) File "c:\users\narfel\gitrepos\windows\gpxtrackposter\venv\lib\site-packages\gpxtrackposter\track_loader.py", line 202, in _load_tracks t = future.result() File "C:\Python\lib\concurrent\futures_base.py", line 432, in result return self.get_result() File "C:\Python\lib\concurrent\futures_base.py", line 388, in get_result raise self._exception AssertionError

If i don't change anything and try to run it i get this:

Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170407-113830-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170415-133258-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170401-113726-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170426-065825-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170412-135126-Ride..gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170424-103748-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170420-125954-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170428-070823-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170414-161140-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170425-072507-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170409-120725-Ride.gpx: Something went wrong when loading GPX. Error while loading C:\Users\Narfel\Gitrepos\Windows\activities\20170423-070251-Ride.gpx: Something went wrong when loading GPX. No tracks found!

[yihong0618]

@narfel That's because Windows dosen't support "-" in filename. you can rename these like 20170423_070251_Ride.gpx and have a try.

[flopp]

@yihong0618 I think - in Windows filenames are perfectly fine.

[yihong0618]

yes, I am wrong...

[narfel]

Tried it anyway, no dice. I even used good old 8.3 format for good measure. But since i can do the i/o stuff on the exact same files with gpxpy i think that is not an issue of the filesystem.

[flopp]

I guess it has something to do with the concurrent loading via concurrent.futures.ProcessPoolExecutor

[narfel]

Yes, that's the part that goes wooshing straight over my head. I found a couple of references to oncurrent.futures.ProcessPoolExecutor on StackExchange, but in absence of a error message other than AssertionError i can't really dig into it. I'm gonna give it a shot without venv. The last link above might be a hint to that.

update: same exact behaviour outside of venv.

[luiscruz]

I am having the same issue here. Downloaded GPX files from strava.

Error while loading *****/Documents/gpx/Evening_Ride.gpx: Something went wrong when loading GPX.
Error while loading *****/Documents/gpx/Morning_Run.gpx: Something went wrong when loading GPX.
No tracks found.

[flopp]

@luiscruz is this on a Linux machine?

[luiscruz]

Hi @flopp , this is on a Mac OS Catalina Version 10.15.7

[wlhUser]

Hello, I just stumbled upon this issue. Don't know if it is fixed meanwhile. If not, I had the problem with 'ProcessPoolExecutor' on Windows as well. After some research I replaced it in _trackloader.py with concurrent.futures.ProcessPoolExecutor() as executor: with: with concurrent.futures.ThreadPoolExecutor(max_workers = 5) as executor:

This worked for me. Maybe you want to try it.

Best Regards, and @flopp, thanks a lot for the great application.

[narfel]

Sweet, thank you, can confirm that works perfectly under Windows. I still have no clue what that actually is about, but i came across some threads that seemed to suggest something similar. I hope it works for Mac OS, too.

[flopp]

@wlhUser thank you for your research!

[flopp]

I've just added a command line option --workers NUMBER_OF_WORKERS.

• If omitted, the default number of processes will be used for track loading (~ number of CPU cores);
• if > 1, the specified number of processes will be used;
• if <= 1, tracks will be loaded without any multi-processing (in a plain for-loop without concurrent.futures...)

So, if there are any problems with loading, --workers 1 should help.

[flopp]

Can you check if this works on Windows & MacOS?

[narfel]

Works on windows for smaller sets of files without specifying --workers NUMBER_OF_WORKERS. If i use a >500 files folder it errors out with TypeError: can't compare offset-naive and offset-aware datetimes unless i specify 5 workers. There seems to be some cashing going on and I'm not sure how to empty it.

[flopp]

Oh, I see. So I guess there is an (uncaught?) exception (related to comparing datetimes with and without timezone info) that kills the loader process...

[luiscruz]

After specifying --workers 1, I was able to generate my poster successfully on my Mac! Thanks!!

[Pataclop]

tried on windows, this works well with --workers 1 , but on a mac on big sur (11.7) this doesn't fix the issue, no matter the number of workers.

[cah-jonathan-cachat01]

I've just added a command line option --workers NUMBER_OF_WORKERS.

• If omitted, the default number of processes will be used for track loading (~ number of CPU cores);
• if > 1, the specified number of processes will be used;
• if <= 1, tracks will be loaded without any multi-processing (in a plain for-loop without concurrent.futures...)

So, if there are any problems with loading, --workers 1 should help.

Lovely, this FIXED all issues for me - Mac M1, os v14.5