Check 1 — Are you right-clicking the surface that has a menu?

Context menus in PlotJuggler belong to specific surfaces — a plot, a curve, a series in the list — and right-clicking empty chrome, a toolbar or a panel border legitimately produces nothing, or the desktop’s own behaviour. Before concluding anything is broken, right-click directly on a plotted curve and directly on a series name, and compare. Two workflow facts belong here: the long-standing way to build an XY plot is a right-button drag pairing two series (press, drag, release — not a click), so a “menu” that appears when you meant to start an XY drag may be the gesture being read as a click; and the current tracker carries a directly related report — “Can’t create XY plots from streaming topics: right-click ‘Force topic streaming’ menu blocks the XY right-drag” (issue #1428, open) — in which a streaming-topic context menu interferes with exactly that right-drag workflow. If your case involves streaming topics and XY plots, that report is your reference point, and using a loaded file’s series instead of a streaming topic is a practical sidestep while it stands.

Check 2 — Focus and window-manager behaviour

• Give the window focus first. Left-click once inside the PlotJuggler window, then right-click. On some desktops the first click of any kind is consumed to raise and focus the window — the click worked, it just went to the window manager instead of the application.
• Check for desktop-level interception. Tiling window managers, global gesture tools, and “right-click on title bar” system menus can claim right-clicks before applications see them. The control test is another Qt application on the same desktop: if right-click menus misbehave there too, you have a desktop configuration question, not a PlotJuggler question.
• High-DPI oddities are a documented class. The tracker has fielded menu-rendering complaints under high-DPI conditions (menus overlapping and rendering unnaturally, issue #468). If menus appear but in the wrong place or half off-screen, note your display scaling before assuming the click failed — the menu may have opened where you were not looking.

Check 3 — Remote desktop, VMs and screen sharing

If you use PlotJuggler over a remote desktop, a VM console or a screen share, right-click is one of the first gestures those layers remap, delay or swallow — some send it only on release, some translate it into a long-press, some reserve it for the host. The honest test costs two minutes: sit at the machine (or a direct local session) and repeat the same right-click on the same plot. If it works locally, PlotJuggler was never the problem, and the fix — if any is needed — lives in your remote tool’s mouse settings. This is also why reports of this symptom rarely reproduce for other users: the variable is the layer between the mouse and the application, which only you can see.

Check 4 — Your version, and the update path

Right-click behaviour is also version-sensitive in practice — issue #1428 above is an open report against PlotJuggler 4.0.0 itself, describing a right-click menu that fires on mouse press on Linux and blocks a drag. That supports one practical conclusion: if you are on an old build, updating is a real diagnostic step. Current releases are PlotJuggler 4.0.0 and PlotJuggler 3.17.2, both on the Download page, with install routes in the Install hub. Update, then repeat the exact clicks that failed — same plot, same series. If the behaviour changes, stay on the current version; if it does not, you have at least removed version drift from the list, which is what a checklist is for.

Workarounds while you diagnose

• Do the task another way once. Most menu actions in a plotting tool have a second path — a toolbar control, a different panel, or rebuilding the view. Getting your analysis done today matters more than winning the argument with the context menu.
• Use left-drag workflows where they exist. Time plots are built with left-button drags from the series list; only the XY pairing specifically uses the right-button drag. The XY plot tutorial and drag-and-drop guide cover both gestures.
• Record the specifics if you report it. Version, operating system, local or remote, which surface you clicked, and whether other applications behave the same way. A report with those five facts is actionable; “right click doesn’t work” alone — as the search phrase shows — is where everyone starts, not where a fix starts.

If the menu works but the action behind it fails, your symptom has changed categories — return to the Troubleshooting hub and follow the guide for the new symptom.

Related guides on this hub: if the gesture that fails is a drag rather than a click, see large-file performance checks for recordings that make every interaction feel heavy, and AppImage won’t open if you are running the AppImage in a session where other input behaviour is also unusual.

Separate the three costs first

Name which row you are in. A slow load will not be fixed by hiding curves, and slow interaction will not be fixed by a faster disk. The tracker shows users hitting these separately: “Loading multiple rosbags becomes progressively slower” (issue #896) is a loading-cost report, as is “Loading an overly large ulog file” (issue #1116), while “Performance loss on 3.9.0” (issue #936) is a reminder that version-to-version performance can genuinely change — one more reason the checks below start with knowing your version.

Loading checks

• Load one recording at a time. Issue #896’s title is the finding: loading additional rosbags into the same session becomes progressively slower. For big investigations, one recording per PlotJuggler instance — comparing runs in two windows — can be faster to work with than one overloaded session. Our multiple-bag comparison tutorial covers the deliberate, aligned way to compare when you do load several.
• Mind the ULog size cliff. The project’s own content-gap landscape names ULog files over 2 GB as a known hard case for this workflow. If your .ulg is in that territory, expect the load to be the expensive step, plan for it (load once, then work from a saved layout), and treat “the same file loads slowly on every machine” as information about the file, not about your install.
• Know your format’s parsing cost. A loader must parse every message it reads; structured binary recordings and text formats do not cost the same per point. If one format is consistently your bottleneck, recording or converting future captures into the format your workflow handles best is a legitimate upstream fix.
• Check the version. Performance work continues upstream — a current feature request asks for “faster, progress-reporting and truncation-tolerant ULog import” (issue #1418) — so being on a current release (PJ3 3.17.2 or PJ4 4.0.0, from the Download page) is a real check, not boilerplate.

Interaction checks: plot less, see more

Once the data is in, the cheapest performance technique is not a setting — it is restraint. PlotJuggler is built to render millions of points, but every visible curve at full density is work the GPU must repeat on every zoom and pan. Practical habits, in order of payoff:

1. Plot only the series the current question needs. Thirty visible curves is a reading problem before it is a performance problem; both get better when you cut to the five that matter. Keep the rest loaded, just not drawn.
2. Downsample or decimate for overview work — as a technique, honestly labelled. When you are scanning an hours-long recording for the interesting minute, a reduced-resolution copy of a series (fewer points, same shape) is the standard general technique: compute it as a derived series or produce a reduced export of the segment you care about, and return to the full-density data for the detailed inspection. This is general data-handling advice, not a hidden PlotJuggler switch — do not mistake a downsampled overview for the data itself when measuring peaks.
3. Zoom before you judge performance. Interaction cost scales with what is on screen. A tool that feels heavy showing a whole flight can feel instant inside a ten-second window; evaluate responsiveness at the zoom level you actually analyse at.
4. Be deliberate with derived series. Every transform, custom function and resampled curve adds points the session must hold and draw. They are worth it — that is the point of the tool — but a layout that computes a dozen derived series “just in case” is carrying weight on every interaction. Build them when the question needs them; the Lua custom functions tutorial covers building them well.

When slow is a signal, not a nuisance

If a recording that used to load comfortably suddenly does not — on the same machine and version — treat the change as data: a logger that started recording more topics, a higher sample rate, a longer capture. And if one specific file is slow everywhere while similar files are fine, suspect the file (unusually many series, an awkward structure, partial damage) before suspecting PlotJuggler; the MCAP guide covers the damaged-file branch for that format. Rule of thumb for the whole topic: PlotJuggler’s documented design centre — thousands of series, millions of points, OpenGL rendering — covers most real logs comfortably. When you are outside that centre, the fixes are workflow fixes: fewer simultaneous recordings, fewer visible curves, reduced-resolution overviews, and a current version. Those are unglamorous, and they are what actually works.

More symptoms and fixes are indexed on the Troubleshooting hub; install-side slowness and start-up problems belong to the Install guides.

Related guides on this hub: if a large recording will not load at all — rather than loading slowly — work through ROS 2 plugin not loading for ROS bags and missing data loaders explained for other formats, before returning to the performance checks above.

Cause 1 — You are on PJ3 without the MCAP plugin set

In the PJ3 world, rosbag2 and MCAP support lives in the ROS 2 / MCAP plugin set — the separate plotjuggler-ros-plugins package — not in a standalone PJ3 binary. A PJ3 install without that package has no MCAP loader, and the file will be refused for the reason explained in missing data loaders explained. The documented install is sudo apt install ros-$ROS_DISTRO-plotjuggler-ros, launched with ros2 run plotjuggler plotjuggler; if the plugin layer itself is in question, work through ROS 2 plugin not loading first. This failure class is well attested on the project tracker, under titles such as “cannot open mcap bags” (issue #783) and “Error reading the mcap file” (issue #754) — real reports, with real files, that mostly resolve into route and environment questions.

Cause 2 — You expected PJ3 behaviour from PJ4, or the reverse

PlotJuggler 4 reads MCAP natively. MCAP is on PJ4’s own file list, alongside CSV, Parquet, PX4 ULog, LeRobot, MP4, PCD and PLY — no ROS installation is required for the file itself. So the diagnostic fork is sharp: if a plain .mcap will not open in PJ4, the plugin-route explanation does not apply, and you should look at the file itself (causes 3 and 4 below) and at whether your PJ4 build is current — 4.0.0 from the Download page. Conversely, if it opens in PJ4 and not in your PJ3, nothing is broken: the generations differ here by design. One tracker report captures a subtler version of this — “Having trouble opening an mcap file created on Linux in PlotJuggler for Windows?” (issue #958, still open) — a reminder that where a file was written, and with what message definitions, can matter as much as where it is read.

Cause 3 — The recording needs its message context

An MCAP file is a container of timestamped, topic-structured messages, and reading it means understanding the messages inside it. Phrase this carefully, because it is where folklore grows: a rosbag2 recording carries a storage identifier — the recording’s metadata names which storage implementation wrote it (MCAP being one of them) — and readers use that recorded structure to interpret the data. When a recording was written with custom message types, the reading side needs those message definitions available; a reader that lacks them can fail on a file that is perfectly intact. In practice: if the file came from a ROS 2 system with custom messages, open it in an environment that has those definitions — typically the ROS route, on the machine (or a machine configured like the one) that recorded it. If the same file opens on the recording machine and nowhere else, this is almost certainly your cause, and it is an environment fix, not a file repair.

Cause 4 — The file is actually damaged

Recordings get truncated — a recorder killed mid-write, a copy interrupted, a disk that filled up. Here the version history genuinely helps you: during the PJ4 preview cycle, 3.999.9 (10 August 2026) specifically added improved reading of corrupted MCAP files, and that capability shipped in the 4.0 line. So the practical advice is concrete: a damaged MCAP that a strict reader rejects is worth one attempt in a current PJ4 before you declare it lost. Keep expectations honest — “attempt” is the project’s own framing, not a promise of recovery — and work on a copy of the file, never the only original. If PJ4 recovers the data, export or re-save what you need immediately (PJ4 can export to CSV and Arrow-Parquet) rather than trusting the damaged container for future sessions.

A diagnostic order that respects all four causes

1. State your line out loud: PJ4 (native MCAP) or PJ3 (plugin route)? Half of all MCAP confusion dies here.
2. On PJ3: confirm the ROS plugins package is installed for your distribution and launch via ros2 run.
3. Test a second, known-good MCAP if you can get one. If it opens, your install is healthy and the problem is this specific file.
4. Ask where the file was recorded and whether custom messages were involved; if so, reproduce that message environment.
5. Suspect damage only after the route checks — then try the file, as a copy, in current PJ4 for its corrupted-file reading.

For the normal opening workflow once it works, see the ROS bag and MCAP tutorial and the Tutorials hub. Other symptoms are indexed on the Troubleshooting hub.

Check 1 — Is the ROS plugins package actually installed?

PlotJuggler is not itself a ROS application; ROS is supported through external plugins in the plotjuggler-ros-plugins repository. The documented Debian route installs the application and the plugins together:

sudo apt install ros-$ROS_DISTRO-plotjuggler-ros

A standalone PlotJuggler — from GitHub binaries, the snap or an AppImage — does not become ROS-capable by wishing. If you never installed this package on this machine, the plugin is not “failing to load”; it was never there. This is the same architecture explained in missing data loaders explained: the rosbag DataLoader, the topic subscriber and the re-publisher all live in this plugin set.

Check 2 — Does the package match your ROS distribution?

The ROS Index lists plotjuggler_ros at version 2.3.1 for the distributions humble, jazzy, kilted, lyrical and rolling. Three consequences follow. First, $ROS_DISTRO must actually resolve to your distribution when you install — echo it in the same terminal if you are unsure. Second, a package built for one distribution is not interchangeable with another; a Humble plugin set in a Jazzy environment is a mismatch, not a near miss. Third — and routinely missed — from v2.3 onward the plugins line supports ROS 2 only; ROS 1 plugin support is frozen in older versions, so a ROS 1 expectation against a current plugin install will present exactly like a loading failure. Availability is a live question on the tracker as well: the plugins repository carries reports such as “Package ros-lyrical-plotjuggler-ros is not available”, which is what a distribution gap looks like from the user’s side.

Check 3 — Did you launch it through the ROS environment?

The documented launch is:

ros2 run plotjuggler plotjuggler

That is logical guidance, not ritual. Launching via ros2 run in a terminal where your ROS setup is sourced guarantees that PlotJuggler starts inside the environment the plugins were built for — the same distribution, the same libraries, the same message definitions. Launching a bare executable from a desktop icon, or from a terminal where ROS was never sourced, can produce a PlotJuggler that runs perfectly and sees no ROS world at all. If the plugin appears when launched the documented way and not otherwise, you have found your cause: always launch it that way. The tracker’s ROS 2 reports underline how environment-sensitive this layer is — from “ROS2 topic subscriber is not connecting” (issue #1013) to “Custom message package not found” (issue #762), where the plugin was present but the user’s own message definitions were not visible to it.

Check 4 — Is your install channel confining the plugin?

• Snap: the PJ3 documentation recommends the snap on Ubuntu, including for ROS users, while noting it works with ROS 2 with some limitations. Confinement is the mechanism behind most of those limitations, and the tracker has the matching report: “Snap installation doesn’t work with custom built messages” (issue #1379). If your workflow uses custom message packages, the apt ROS package is the documented route — not a workaround.
• Source builds: the documented source route clones plotjuggler_msgs, the main repository and plotjuggler-ros-plugins into one workspace, then runs rosdep install and colcon build. A partially built or unsourced workspace produces exactly the “plugin not loading” symptom; rebuild completely and source the workspace before launching.
• Mixed lines: PlotJuggler 4 does not make the PJ3 ROS plugin packages load — the ROS ecosystem is still on the PJ3 line. Expecting PJ4 to pick up plotjuggler_ros plugins is a line mismatch, covered in our PJ3 vs PJ4 comparison.

Putting it together

1. In one terminal: source your ROS setup, confirm echo $ROS_DISTRO names your distribution.
2. Confirm the package: sudo apt install ros-$ROS_DISTRO-plotjuggler-ros (it will report already-installed if present).
3. Launch only this way for the test: ros2 run plotjuggler plotjuggler.
4. Test with a bag or topic you know is good. If ROS features appear now, standardise on that launch method.
5. If they still do not appear and you are on the snap with custom messages, switch to the apt route from the Install hub and retest before digging deeper.

If the plugin loads but a specific recording still refuses, the problem has moved downstream — continue with MCAP file won’t open or return to the Troubleshooting hub. Files and versions are on the Download page.

Check 1 — Make the file executable

A downloaded AppImage is data until you mark it as a program. The PJ4 documentation’s own instruction is exactly this: download PlotJuggler-<version>-x86_64.AppImage, run chmod +x on it, then run it. If you skipped that step, a double-click will do precisely nothing, and that is the system working as designed.

chmod +x PlotJuggler-4.0.0-x86_64.AppImage
./PlotJuggler-4.0.0-x86_64.AppImage

Run it from a terminal, at least for diagnosis. A terminal launch shows you any message the program or the runtime prints on failure, while a file-manager double-click hides all of it. Most AppImage mysteries stop being mysteries the moment they are launched once from a terminal. The full AppImage walkthrough, including where to keep the file, is in the Ubuntu install guide.

Check 2 — Your glibc version (PJ4 requires 2.35 or newer)

This is the check specific to PlotJuggler 4, and it is a hard requirement, not a recommendation: the PJ4 AppImage requires glibc ≥ 2.35 — Ubuntu 22.04 or later, or an equivalent distribution. On an older system the file can be perfectly downloaded, correctly marked executable, and still unable to run, because the system library it was built against is not there. Check yours with:

ldd --version

If the version is below 2.35, re-downloading the same AppImage will never help. Your realistic options are a newer system, the PJ3 AppImage builds (PJ3 also shipped an aarch64 AppImage, which PJ4 does not), or building from source. Do not spend an afternoon fighting a version floor — it does not negotiate.

Check 3 — FUSE and the AppImage runtime (general Linux guidance)

Flagged honestly as general Linux guidance, not a PlotJuggler-specific fault: AppImages traditionally rely on FUSE support to mount themselves when run, and some minimal or newer-default systems lack the compatibility library AppImages expect. The symptom class is “the AppImage will not run at all on this system, for any AppImage”. The test is simple: try a different, known AppImage. If no AppImage runs, the problem is your system’s AppImage support — consult your distribution’s documentation for its FUSE library package — and the direct fix for PlotJuggler specifically is to stop using the AppImage format and install the .deb instead (next section). Launching from a terminal, again, is how you see this class of failure instead of guessing at it.

Check 4 — Architecture and download integrity

• Architecture: PJ4 4.0.0 ships an x86_64 AppImage only. There is no PJ4 aarch64 AppImage; on ARM hardware, that file will never run, however correct everything else is. PJ3 is the line with an aarch64 AppImage.
• Integrity: compare the file’s SHA-256 with the GitHub digest published on the Download page (sha256sum <file>). A truncated or corrupted download fails in ways that imitate every other check on this page; ruling it out takes a minute.
• It is a real tracker topic, too: the project has fielded reports such as “Errors when launching AppImage” (issue #816) and, in the PJ4 era, an AppImage that had silently lost a streaming plugin (issue #1420) — a reminder that if the program opens but a feature is missing, that is a different guide: missing data loaders.

The escape hatch: install the .deb or use the apt repository instead

On Debian and Ubuntu, the AppImage is the portable option, not the only option — and for a machine you use every day, it is arguably not the best one. PJ4 offers a single-release .deb (plotjuggler4_4.0.0-1_amd64.deb) installed with sudo apt install ./plotjuggler4_4.0.0-1_amd64.deb, and, new in this generation, an official apt repository that keeps PlotJuggler 4 updated through your normal system upgrades:

curl -fsSL https://apt.plotjuggler.io/pj4_install.sh | sudo sh
sudo apt install plotjuggler4

The repository route is documented for Ubuntu 22.04+ and Debian 12+, and it sidesteps the executable-bit and FUSE questions entirely, because a package manager does that work. Step-by-step instructions are in the apt repository guide and the Ubuntu install guide; all channels start from the Install hub. If PlotJuggler now opens but a file will not, continue on the Troubleshooting hub.

Related guides on this hub: if the AppImage opens but a ROS feature or file format is missing once it runs, that is a plugin question — see ROS 2 plugin not loading; and if the program opens but files will not drop into it under Wayland, see drag and drop not working.

First, which drag is failing?

Be precise about which row you are in before changing anything — the checks below barely overlap. The baseline workflows, so you can compare against intended behaviour, are in Getting Started with PlotJuggler and the Tutorials hub.

If the file will not drop

1. Rule out a loader refusal dressed as a drag failure. If the drop “does nothing” only for one file type — bags and MCAP recordings are the usual ones — test the same gesture with a small CSV. If the CSV loads, dragging works and the missing piece is a plugin: see “No such plugin”: missing data loaders explained and, for recordings specifically, MCAP file won’t open.
2. Check your session and install channel as variables. Drag behaviour is partly a property of the desktop session and the packaging, not just the application — the clearest documented case is the right-drag one in the next section, where on Linux the context menu fires on mouse press rather than release (issue #1428, reported from a Wayland session). As control tests, try the same drag in a different session type (Wayland vs X11) and, if you run the AppImage, try the .deb / apt install instead, as covered in the Install guides. If the drag works in one combination and not another, you have localised the problem without touching your data.
3. Drop onto the window, from a real file manager. Drags that start inside another sandboxed application, a browser download bar or a remote-desktop window can be intercepted before PlotJuggler ever sees them. Save the file locally and drag it from the system file manager as a control test.
4. Check basic file facts. Confirm the file exists where you think it does, is readable by your user, and is complete — a recording still being copied or written by another program is a file problem, not a PlotJuggler problem. These are checks to perform, not error messages to expect.

If the series will not drag onto a plot

1. Confirm data is actually loaded. A series can only be dragged after a file has loaded and populated the list. An empty list after a “successful” drop points back to the loader question above.
2. Drag the series name, drop on the plotting area. The documented gesture is list → plot area. Dropping onto toolbars, the timeline scrubber or another panel is not the same target and being rejected there is expected behaviour.
3. Mind the mouse button for XY plots. The long-standing workflow pairs two series for an XY plot with a right-button drag. If a right-drag produces a menu instead, read Right-click menu not working — and note the current tracker report (#1428) in which a right-click streaming menu interferes with the XY right-drag from streaming topics.
4. Know that drag-related bugs have existed and been fixed. The tracker, for example, carries a closed report titled “Some Mouse Events not Captured After Drag and Drop” (issue #716). If you are on an old build, updating to a current release — PJ3 3.17.2 or PJ4 4.0.0, from the Download page — is a rational step, not superstition.

Environment checks that apply to both gestures

• Remote desktop and VMs: drag-and-drop between host and guest is a separate feature from dragging inside one application, and it is frequently disabled. Test with a purely local file and a purely local drag first.
• Window focus: click once inside the PlotJuggler window to give it focus, then drag. A drag that starts while another window holds an active grab can be swallowed by the desktop.
• One gesture at a time: after any change — different install channel, updated version, different session type — retest with the same small file and the same series, so you know which change mattered.

If dragging works with a small CSV but your real recording still will not load, the drag was never the problem: continue with missing data loaders or large-file performance checks if the file is very big. Everything else is indexed on the Troubleshooting hub.

Why PlotJuggler answers this way: loaders are plugins

PlotJuggler’s core is deliberately small. The documented plugin architecture splits capability into DataLoaders (read files), DataStreamers (receive live data), Message Parsers (understand encodings) and Toolboxes, all extendable in C++, with a sample-plugins repository for authors. CSV and PX4 ULog loading ship with the classic application; other formats arrive through plugin packages. So a “no plugin for this file” outcome is not PlotJuggler failing to recognise a file it should know — it is PlotJuggler truthfully reporting that the loader for that format is not present in this installation. That is also why two machines can behave differently on the same file: they do not have the same plugins installed.

This is not a theoretical edge case. On the project’s GitHub tracker, users have filed exactly this class of failure — for example two reports titled “The plugin [DataLoad ROS bags] thrown the following exception: map::at” (issues #901 and #991), where the ROS bags plugin itself threw an exception instead of loading the data. An older report, “AppImage fails to load ROS related plugins and/or ROS bags” (issue #166), makes the same point from the packaging side: the application was present, the ROS plugin layer was not reachable.

The most common case: ROS bags without the ROS plugins

ROS support is the textbook example, because PlotJuggler is not itself a ROS application. The project’s own description is explicit: ROS is supported through external plugins in the separate plotjuggler-ros-plugins repository — a DataLoader for rosbags (ROS 1 and ROS 2), a ROS topic subscriber, and related tools. A standalone PlotJuggler install without that plugin set has no way to open a .bag file or a rosbag2 recording, however healthy the file is. The fix is to install the plugins the documented way:

sudo apt install ros-$ROS_DISTRO-plotjuggler-ros
ros2 run plotjuggler plotjuggler

That package is version 2.3.1 on the ROS Index, listed for the distributions humble, jazzy, kilted, lyrical and rolling, and from the v2.3 series the plugins line supports ROS 2 only. The full walkthrough — including why launching through ros2 run matters — is our ROS 2 install guide, and the loading-specific version of this problem has its own guide: ROS 2 plugin not loading.

Check the packaging limitation before reinstalling

• Snap installs have documented limits. The PJ3 documentation recommends the snap (sudo snap install plotjuggler) on Ubuntu, including for ROS users, while noting it works with ROS 2 with some limitations. A confined snap is exactly the kind of install where an external plugin or a custom message type may not be reachable. If your workflow depends on ROS plugins, the apt ROS package route is the safer default.
• An AppImage is one file, not an ecosystem. The AppImage carries the application; it does not magically carry your system’s ROS plugin libraries. Issue #166 above is the historical record of that mismatch.
• Check the file extension honestly. A loader claims formats it understands. A file renamed to a familiar extension, or a rosbag2 recording folder treated as if it were a single file, can present as a missing-plugin problem when the real issue is what you handed it.

The PJ4 answer: the Extensions Marketplace

PlotJuggler 4 (4.0.0) keeps the plugin model and gives it a distribution channel: the Extensions Marketplace (File → Marketplace), backed by the project’s public plugin registry, where loaders, streamers, parsers and toolboxes can be installed and updated from inside the application. PJ4 also widens what is built in — its native file list includes CSV, MCAP, Parquet, PX4 ULog, LeRobot, MP4, PCD and PLY — so some files that needed a plugin route under PJ3 open directly in PJ4; MCAP is the clearest example, covered in MCAP file won’t open. Our Marketplace guide explains how installing extensions works. Note the honest limit: the ROS package ecosystem is still built on the PJ3 line, so “switch to PJ4” is not the fix for a ROS-bag loader gap — installing the ROS plugins is.

A short diagnostic order

1. Confirm a built-in format works: load a small CSV. If that fails too, you have a broader install problem — go to the install troubleshooting guide.
2. Name the format you actually need (ROS 1 bag, rosbag2/MCAP, a CAN log, a custom format) and identify which plugin provides it.
3. Check how this copy of PlotJuggler was installed (standalone, snap, AppImage, ROS apt package) and whether that channel can carry the plugin.
4. Install the missing piece by its documented route, restart PlotJuggler, and retest with the same file.
5. Still stuck? Compare notes with the sibling guides on this hub — MCAP won’t open and ROS 2 plugin not loading cover the two most specific versions of this problem.

Files for both lines, with checksums, are on the Download page. The symptom index for everything else is the Troubleshooting hub.