DB: trip is unreliable

[derhuerst]

For 8011160 (Berlin Hbf) to 8000309 (Regensburg Hbf), it reports an empty direction:

const berlinHbf = '8011160'
const regensburgHbf = '8000309'
client.journeys(berlinHbf, regensburgHbf, {results: 1, tickets: true})
.then(([journey]) => {
	const firstLeg = journey.legs[0]
	return client.journeyLeg(firstLeg.id, firstLeg.line.name)
})
.then((data) => {
	console.log(require('util').inspect(data, {depth: null}))
}, console.error)

node demo.js | grep direction
#   direction: null

Apparently for non-ICE journey legs, it fails completely. E.g. for 8011160 (Berlin Hbf) to 8010035 (Berlin Karlshorst):

{ Error: HCI Service: problems during service execution
    at request (/Users/j/web/hafas-client/lib/request.js:52:14)
    at Object.journeyLeg (/Users/j/web/hafas-client/index.js:286:10)
    at client.journeys.then (/Users/j/web/hafas-client/p/db/example.js:19:16)
    at process._tickCallback (internal/process/next_tick.js:178:7)
  isHafasError: true,
  request: 
   { lang: 'en',
     svcReqL: [ [Object] ],
     client: { id: 'DB', v: '16040000', type: 'IPH', name: 'DB Navigator' },
     ext: 'DB.R15.12.a',
     ver: '1.15',
     auth: { type: 'AID', aid: 'n91dB8Z77MLdoR0K' } },
  url: 'https://reiseauskunft.bahn.de/bin/mgate.exe?checksum=1f68d121702ff7ca65a4139a81ff8eaa',
  statusCode: 200,
  message: 'HCI Service: problems during service execution' }

[derhuerst]

Apparently for non-ICE journey legs, it fails completely. E.g. for 8011160 (Berlin Hbf) to 8010035 (Berlin Karlshorst)

Can't reproduce this anymore.

[hensur]

Hi,
I just started playing around with your work because I wanted to analyze how often my train is late.
I think this could be accomplished with the delay information from a journeyLeg request.
However, I don't think this is supported by the DB? Especially not for local trains?

It fails with this message for a local route (I guess it's the same as the one you couldn't reproduce anymore):

{ Error: HCI Service: problems during service execution
    at request (/home/hensur/dev/db-test/node_modules/hafas-client/lib/request.js:52:14)
    at Object.journeyLeg (/home/hensur/dev/db-test/node_modules/hafas-client/index.js:278:10)
    at client.journeys.then (/home/hensur/dev/db-test/index.js:11:16)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  isHafasError: true,
  request:
   { lang: 'en',
     svcReqL: [ [Object] ],
     client:
      { id: 'DB', v: '16040000', type: 'IPH', name: 'DB Navigator' },
     ext: 'DB.R15.12.a',
     ver: '1.16',
     auth: { type: 'AID', aid: 'n91dB8Z77MLdoR0K' } },
  url:
   'https://reiseauskunft.bahn.de/bin/mgate.exe?checksum=785e73cb9952810933d5d6a31399f130',
  statusCode: 200,
  message: 'HCI Service: problems during service execution' }

Source Code:

const createClient = require('hafas-client')
const dbProfile = require('hafas-client/p/db')
  
// create a client with Deutsche Bahn profile
const client = createClient(dbProfile)

client.journeys('8003772', '8000036', {results: 1}) 
.then(([journey]) => {
   const leg = journey.legs[0]
   return client.journeyLeg(leg.id, leg.line.name)
})
.then(console.log)
.catch(console.error) 

[derhuerst]

Yup, I think it fails for trips that are not ICE/IC/RE/RB.

[fnorf]

trip is unreliable indeed!

I was grabbing some departures and then the trips for dates about 1 month in the future in different parts of Germany with the db profile on multiple machines. Now while departures are still coming through just fine, I get errors for pretty much every trip I request the details on. For example:

 '{"lang":"en","svcReqL":[{"cfg":{"polyEnc":"GPA","rtMode":"HYBRID"},"meth":"JourneyDetails","req":{"jid":"1|293395|1|80|16032020","name":"Bus 5","getPolyline":false}}],"client":{"id":"DB","v":"16040000","type":"IPH","name":"DB Navigator"},"ext":"DB.R19.04.a","ver":"1.16","auth":{"type":"AID","aid":"STRIPPED"}}',
  url:
   'https://reiseauskunft.bahn.de/bin/mgate.exe?checksum=STRIPPED',
  statusCode: 200,
  code: 'PROBLEMS',
  message: 'HCI Service: problems during service execution',
  responseId: 'fs6envyggwkhy4w8' }

This is neither focused on a specific mode, product, day, region, IP...

I can request departures for other days and grab their trips just fine, for example these are fine:

• "1|860211|1|80|17032020", "Bus 39"
• "1|679189|21|80|17032020", "Bus 11"
• "1|285240|0|80|16032020", "ICE 23"
• "1|1035926|1|80|16032020", "RUF 593"
• "1|242596|0|80|17032020", "S 1"

Some failing Trip-IDs and their routes:

• "1|592150|0|80|19032020", "BusVB-24"
• "1|651252|4|80|19032020", "BusOF-99"
• "1|276984|1|80|17032020", "RE 3408"
• "1|248369|2|80|19032020", "S 1"

Do you guys have any experience with this kind of error/behaviour? Was I somehow fed fake Trip-IDs?

[fnorf]

Are DB trip IDs maybe not persistent? 🤢
If so, any idea on the time frame in which they are valid?

I successfully got data on "1|1083586|1|80|19032020" but not on "1|1083586|0|80|19032020".

Those are trips passing through "Kölner Str. Ost, Betzdorf", HAFAS ID 377018.

My trip data from the other day shows me "Bus 292" stopping at that stop at 15:26 as part of the trip "1|1083586|1|80|19032020".

If I request the departures again for that same time frame, I get a different trip ID "1|1099335|1|80|19032020" for that specific stop time. I can successfully request data on that trip.

If I try to request data on the trip "1|1083586|1|80|19032020" again (the one that I did successfully scrape earlier), today I get 'HCI Service: problems during service execution'...

[derhuerst]

trip is unreliable indeed!

I was grabbing some departures and then the trips for dates about 1 month in the future in different parts of Germany with the db profile on multiple machines.

This is neither focused on a specific mode, product, day, region, IP...

Because @marudor has figured out what the trip IDs (a.k.a. jids) consist of, they probably know how stable & unique these IDs are.

This is a problem that can be worked around, via an mgate.exe method called JourneyMatch, trainsearch.exe, or manually matching by querying departures. It is so complex and error-prone that we should wrap it into a small library, so that every can benefit from the abstraction.

Nevertheless, the fact that trip (the underlying mgate.exe call is JourneyDetails) is unreliable is still very annoying, and I'd like to find a way to handle it without putting layers of abstraction on top.

[derhuerst]

This doesn't seem to be an issue anymore.