Tracking URL does not resolve correctly

When I select “Tracking URL Parameters” everything works fine. When I select the analytics, the URL does not resolve correctly and none of my content will play. Is there something else I need to change?

Hi Chris!

Which URL exactly does not resolve? The one of the Podlove Analytics page – .../wp-admin/admin.php?page=podlove_analytics – or that of the tracked media files: .../podlove/file/.../s/download/c/.... If the latter, please check the Debug Tracking section in the Podlove | Expert Settings | Tracking tab. Is any item marked with as failed?

In both cases, please also copy-paste the Podlove | Support section here, if there are any warnings of errors. Clicking the Repair button in that section might also help already.

Kind regards,

It’s the tracked media files that do not resolve.


:heavy_check_mark: Rewrite Rules Exist
✘ URL does not resolve correctly
:heavy_check_mark: Consistent protocol chain

PHP Version 5.6.10
WordPress Version 4.2.2
Publisher Version 2.2.4
Web Player Version 2.0.17
Twig Version 1.18.1
open_basedir //customers/2/3/0/
curl Version 7.26.0
iconv available
simplexml ok
max_execution_time 50
upload_max_filesize 96M
memory_limit 256M
disable_functions disk_total_space, diskfreespace, exec, system, popen, proc_open, proc_nice, shell_exec, passthru, dl
permalinks ok (/%postname%/)
podlove_permalinks ok
podcast_settings ok
web_player ok
podlove_cache on
mp3 audio/mpeg


  • The PHP setting “open_basedir” is not empty. This is incompatible with curl, a library required by Podlove Publisher. Please ask your hoster to unset “open_basedir”.
    0 notices

Hm… The only other case of this I find was caused by a problematic nginx caching rule. Have you tried clearing the cache or looking for such rules for mp4, m4a and such media files?

This is required to work around the "open_basedir" is not empty issue. Your suggested change will, I think, only break it more :smile:

I see you’re using Varnish for caching. That might be involved.

Ouch. Edited. :blush: In my defense: It was the same advice you suggested in an earlier instance of the same problem, which it did solve in my podcast.

Ah, I knew that change looked familiar :wink: But should not be required any more, was fixed in 2.1.2.