~derf / projects / db-infoscreen

db-infoscreen (formerly db-fakedisplay) shows departures at german train stations, serving both as infoscreen / webapp and station board look-alike.

Thanks to the undocumented IRIS backend, it usually has very detailed information about delay reasons and service limitations.

There's a public db-infoscreen service on finalrewind.org. You can also host your own instance if you like, see the Setup notes below.

Online db-infoscreen service


mobile view mobile view

example output


  • perl >= 5.10
  • Cache::File (part of the Cache module)
  • Mojolicious
  • Travel::Status::DE::DBWagenreihung >= 0.00
  • Travel::Status::DE::DeutscheBahn >= 2.03
  • Travel::Status::DE::IRIS >= 1.21


db-infoscreen respects the following environment variables:

Variable Default Description
DBFAKEDISPLAY_LISTEN http://*:8092 IP and Port for web service
DBFAKEDISPLAY_STATS None File in which the total count of backend API requests (excluding those answered from cache) is written
DBFAKEDISPLAY_HAFAS_CACHE /tmp/dbf-hafas Directory for HAFAS cache
DBFAKEDISPLAY_IRIS_CACHE /tmp/dbf-iris-mian Directory for IRIS schedule cache
DBFAKEDISPLAY_IRISRT_CACHE /tmp/dbf-iris-realtime Directory for IRIS realtime cache
DBFAKEDISPLAY_WORKERS 2 Number of concurrent worker processes

Set these as needed, create templates/imprint.html.ep (imprint) and templates/privacy.html.ep (privacy policy), and configure your web server to pass requests for db-infoscreen to the appropriate port.

You can run the app using a Mojo::Server of your choice, e.g. perl index.pl daemon -m production (quick&dirty, does not respect all variables) or hypnotad (recommended).

System requirements

Resource requirements depend on usage. For a few requests per second, about 50MB (150k inodes) cache and one or two CPU cores should be sufficient. db-infoscreen typically needs 50MB RAM per worker process, though calculating with 100MB per worker is recommended to leave a safety margin.