Thanks a lot for this update! I updated to new version on openrepos and am very glad to see information about journeys with Deutsche Bahn work again - althoug timetables still don’t work for me (on Xperia 10ii with Sailfish 4.6)
Many thanks! This is awesome 
1 Like
Thank you very much. It works again. Great!
Thanks @poetaster
I’ll past the information forward.
2 Likes
I just checked and the chum version in testing also doesn’t show time tabels. I’ll have a look again.
1 Like
What is the problem?
I’ve kept the lines and just commented them as in fahrplan/src/parser/parser_movas_bahnde.cpp at e37a0d288a2d70cf65c59c6b9b58cdb10d4d3327 · poetaster/fahrplan · GitHub
It still doesn’t show timetables, for instance, for Sbahn Ostkreuz in Berlin.
with qDebug I can see that results are obtained. Just not displayed 
Shall I dig a bit more?
1 Like
Not a problem, a request. I’d like to take over the fahrplan2 repo in harbour since Andreas hasn’t been maintaining it for many years. But, he also hasn’t responded to my mails in years
In any case, it would be nice to also have updated fahrplan2 in the store. Thanks!
Thank you so much for the new version. Oeffis was just no match.
It is great to have Fahrplan back again.
Transfering ownership of an app in Harbour would require consent from the original author.
Could you confirm that the original author is Philipp Andreas and I’ll try to contact him …
No timetables for resrobot.se either. No support?
Edit: Sorry, there is some local timetables.
Yes, at least the username matches and the source link in app info points to that github account.
1 Like
Thank you. I’ll see if he’ll consent and how to communicate that!
1 Like
Did you query for a timetable with Direction set? It works for me for “Berlin Ostkreuz” and “Ostkreuz Bahnhof (S), Berlin” if nothing is set for Direction.
Probably should just disable Direction support for now as that will not work reliably either. You just need to comment out the code comparing dest against directionStation.name (parser_movas_bahnde.cpp lines 164 to 168) a few lines below the other check.
The timetable api just returns the name displayed for the last stop (departures) or first stop (arrivals) or some general direction which does not need to correspond to the name of a stop returned by the location api. Only way I can think of to support that right now would be to allow just setting a string for Direction instead of searching for a location or adding a way to filter the results by destination in the timetable view.
Hmmm. Mode is always set to something (Departure by default). How do I ‘unset it’?
EDIT: It’s not like there are no results. I tested qdebug on ‘result’ and it contains items. They just don’t show.
And, the check you had for duplicate conflicting names actually makes sense. I have (my station Hergmühle and it will without your check return results for two stations that are near but one ist tram only and one sbahn only. With your check, it filters correctly.
By not set I meant that the Direction field is set to “please select” by doing a long press and doing “Clear Station”. Mode works correctly.
Ah, sorry, being thick.
Since I’m in it now, I’ll see if I can get rid of the issue with names. Searching on ‘Hegermühle(Strausberg)’ is a bit wearisome, otherwise
Maybe you have an idea, but it looks like the evaNr field can disambiguate (with less parsing) than the locationId ?
EDIT:
"A=1@O=Hegermühle(Strausberg)@X=13866364@Y=52548386@U=80@L=8080680@B=1@p=1742845592@i=U×008003264@"
the L=8080680 is the evaNr. Each QVariant in the entries has evaNr as a simple numerical field. So it’d be parse the L from lastTimetableSearch.id and compare with evaNr. But that’s just my guess seeing the data for Hegermühle(Strausberg)
EDIT: Ok, yes, this works for this case
QStringList idList = lastTimetableSearch.currentStation.id.toString().split("@");
QStringList lList = idList[5].split("=");
QString evaNr = lList[1];
if ( evaNr != entry.value("abfrageOrt").toMap().value("evaNr").toString() ) {
continue;
}
correctly filters out the tram stations which are somewhere else (about 500 meters 
Heh. I’ve just created an app to make city dwellers take the bus So the evaNr ist not enough
Yeah like the old coordinate check it also won’t work for the “Jädekamp, Hannover” case. I just checked and the location api returns L=638939 for that stop and the timetable results lists it as L=616029, evaNr 616029 .