Traccar Compatible Dashcam with GPS: What Actually Works

"Is this camera compatible with Traccar?" is probably the most expensive question in the industry, because it almost always gets answered after the purchase.

This article is the index for the whole series: the list of what actually works, why the question is framed wrong to begin with, and the procedure to verify it yourself in an afternoon instead of finding out with fifty units sitting in your warehouse.

The right question isn't the brand, it's the protocol

Traccar doesn't support cameras. Traccar supports protocols. No brand is compatible or incompatible on its own — the firmware loaded onto the unit is.

The same manufacturer can sell you two models that reach the server through completely different decoders. The Jimi IoT family is the perfect example, and I break it down below. So when a distributor tells you "yes, it's Traccar compatible," the follow-up question that saves you money is always the same:

Exactly which protocol does the unit speak, and on which port?

If they can't answer that in writing, they don't know whether it's compatible.

The two media paths

Before looking at any list, you need to understand that Traccar does two different things with cameras, through paths that never touch. Confusing them is the source of 90% of the frustration:

A camera can give you photos stored on your server or live video, and with the current decoder catalog it's rare to get both from the same setup. Deciding what to buy starts with deciding which column you need. The full mechanism is in how the Traccar media system works.

Protocols that actually implement media

Traccar has more than 270 protocols, and the vast majority don't touch media at all. Going through which decoders actually use the media system, the list is short:

Separately, the Chinese JT/T808 standard (what many vendors call "Huabao," the one nearly every MDVR speaks) follows its own path: it doesn't store files, but it does do live video through the JT/T1078 pipeline that Traccar added in April 2026. If you searched the forum for this and found threads saying streaming isn't supported, they predate that date.

Which command you can send

Three standard command types cover most of the usage:

• requestPhoto — photo on demand. Implemented by Fifotrack, Meitrack, PT502, Ruptela, Meiligao and GPS103. Teltonika and GT06 request photos through their own path. Full detail in how to request a remote photo with requestPhoto.
• videoStart / videoStop — live video, exclusive to the JT808/JT1078 path. I cover it with real production logs in JT1078 live video: how it works and why it drops.

The command showing up in the interface does not mean your unit understands it. The encoder for its protocol has to have implemented it.

Live video is served as HLS, and the channel is in the path

One detail that decides entire deployments and appears in no documentation: Traccar remuxes the JT1078 flow into MPEG-TS and publishes it as HLS from VideoStreamResource, on two paths:

• /api/stream/{deviceId}/{channel}/live.m3u8 — the playlist
• /api/stream/{deviceId}/{channel}/{index}.ts — the segments

The {channel} in the URL is what makes a multi-channel MDVR usable: every camera on the unit gets its own playlist. And if you put a reverse proxy in front without letting /api/stream/ and /api/media/ through, you'll get a playlist that loads and a video that never starts.

Default ports

Taken from PortConfigSuffix.java, not from a forum thread:

Watch out for 5263: there's a claim going around that JT1078 uses 5078 — by analogy with the standard's name — and that is not the case in Traccar.

Case study: the Jimi IoT family

This is the best example of why brand is useless as a criterion. Five models from the same commercial series reach the server through two different doors:

One post each:

• JC181 — dual-channel dashcam, field-tested in production. The only one we've actually run on a real server, which is why it's the reference for the series.
• JC450 — fleet camera with ADAS and DMS. The step up for heavy vehicles and multi-channel setups.
• JC400 — the one that doesn't speak JT808. The odd one out: it goes through GT06, and it's the natural candidate if what you want is files stored on your own server.
• JC371, JC182 and JC451 — the other JT808 models. Same guaranteed behavior at the protocol level, hardware unverified.
• JC261 and JC120 — what to check before buying. They don't appear by name in the code, and that deserves a nuanced explanation.

As for MDVR brands like Howen or Streamax, I found no dedicated decoders in Traccar. That doesn't rule them out — plenty of MDVRs implement JT808 generically — but it does mean nobody has written model-specific logic for them: ask for a demo before signing anything.

How to verify it yourself

The full procedure, in order, with a single sample unit:

1. Ask for the protocol in writing from the distributor: JT808/Huabao, GT06/Concox, or proprietary. And the port.

2. Ask for the LTE bands for your region. This is the most expensive and the dumbest failure: a camera with the wrong bands is a paperweight, no matter how compatible the protocol is.

3. Register the unit in Traccar with its unique identifier and confirm positions are arriving. Without positions there's nothing else to test.

4. Check which decoder it comes in through, in the server log:

   grep -i "YOUR_IMEI" /opt/traccar/logs/tracker-server.log
   

5. Test photos and check whether the file landed on disk:

   ls -la /opt/traccar/media/YOUR_IMEI/
   

6. Test live video and confirm the camera obeyed:

   grep -i "jt1078" /opt/traccar/logs/tracker-server.log
   

   If jt1078 < followed by the camera's IP shows up after videoStart, the session was established. And wait 10 to 15 seconds before clicking again: every retry forces the camera to cancel the session and renegotiate the socket, so insisting is exactly what stops the video from starting.

7. Only then buy the batch.

Before configuring anything

Two settings have to be right or none of the above works:

• media.path — this is the actual switch for the media system (defaults to ./media). If it has a value, the servlet gets registered.
• media.bufferSize — 32 MB by default; larger transfers are discarded. Barely relevant for photos, decisive for video clips.

And one warning that saves afternoons: there is no media.enable key. It's a common forum mistake. All the practical detail — permissions, disk sizing, cleanup, reverse proxy — is in the media.path configuration guide.

Summary for deciding

• Want photos archived on your server? Look for a unit on a media-system protocol: Teltonika, GT06/Concox, Jimi over HTTP, Dualcam, Meitrack, Ruptela.
• Want to see the cabin live? Look for a JT808 MDVR with JT1078, and accept that the recorded footage lives on the vehicle's SD card.
• Want both? Today that means additional development on top of the JT808 decoder, or two separate units. Be clear about that before promising it to a client.